Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

From: Ietf Roll <[email-masked]>
Date: Sat, 3 Sep 2011 00:54:25 -0700 (PDT)

JP Vasseur wrote:

*if* you think that this not elegant enough (which has to be demonstrated IMO), then you must be supportive
of the P2P IDs work that the WG has been working on ?
[rav] how about a demonstration that RPL actually works as purported.  Thomas has said that his group implemented it and it was difficult, complex and fraught with inconsistencies in specification.
         I heard that zigbee is having problems making it work and the only paper that I've seen on RPL says that for constrained nodes they recommend no more than 30 nodes in a network.  Hardly the scale necessary for some of the 
         use cases been suggested (like AMI).

         The P2P is a hack to try to fix the fact the RPL is basically a collection tree and as such downward routing is an distant after thought (certainly not elegant).

         Without lots of memory, node must use non-storing mode (oh and we are talking about constrained devices so lots of memory is then inconsistent) and then routing is up to the root and back down.  Not what anyone who
         understands routing would consider elegant P2P.

         In the rush to get RPL out of the working group we all were bamboozled by the chair into believing the draft was actually complete and the IESG further compounded this error.

         If it were possible to fix things, RPL should be an experimental draft until such time as there are working interoperable implementations that are shown to provide the services that were required in the various Use-case
         drafts - or even just one of them.

         And now we are rushing to generate and publish a marketing document (called an applicability statement) without having any experience with the protocol.

         Are we rushing and putting so much pressure and bending the systems so that this gets published before we find we've built a house of cards and it comes crashing down.

         This will be really counter productive to the industry and the Internet (certainly not Thomas's warnings).  When everyone looks at this mistake and says, why didn't the IETF do its job and exercise proper engineering, then the ROLL WG
          and the Chairs will be the ones that have hurt the industry and the Internet.

Rav

---

From: C Chauvenet <[email-masked]>
Date: Sat, 3 Sep 2011 08:05:34 -0700

Hi,

Le 3 sept. 2011 à 09:54, Ietf Roll a écrit :

JP Vasseur wrote:

You may use this fantastic website : http://scholar.google.fr/ to increase your bibliography about RPL.
There are a lot of paper on RPL, and more and more are coming through the last conferences.

Furthermore, if you were in IETF (but we cannot know...) you should have talk to the main author of the paper you are referring to, to clarify your understanding of that paper (He was in the first row during the ROLL session; hard to miss ...).

All this looks very much to your mail during IETF.
I don't really see the value regarding the object of this discussion, focused on the compression document.
Anyway, you should definitely reduce your coffee consumption ;-)

Rav

<ATT00001..txt>

Regards,

Cédric.

---

From: Mukul Goyal <[email-masked]>
Date: Sat, 3 Sep 2011 10:33:35 -0500 (CDT)

>[rav] how about a demonstration that RPL actually works as purported.  Thomas has said that his group implemented it and it was difficult, complex and fraught with inconsistencies in specification. 

An open-source RPL implementation on Contiki has existed for a while. I am a cursory observer of the Contiki mailing list but it is clear to me that this RPL implementation is quite popular. INRIA (Matthias Phillip and Emmanuel Baccelli) did an RPL-P2P implementation on top of this implementation. This implementatio is uptodate with RPL-P2P version 4. I have checked this code (and also the core RPL implementation code) line by line and I dont see how we can characterize the implementation difficult/complex or fraught with inconsistencies. A second P2P-RPL implementation is in works at Sigma Design.

I hear the zigbee-IP folks have been testing various RPL implementations very aggressively. I have not heard difficult/complex/inconsistent complaints there too (although I have no direct participation in that effort but I hear about the ongings of zigbee-IP activities from people who do). So, I think this particular statement may not be accurate or fair. Perhaps some one from zigbee-IP camp can update us on the situation in this regard.  

I guess I object to rest of this email too. I guess people will realize it for what it is - unfounded libel from a person too afraid to identify himself/herself.

Thanks
Mukul

----- Original Message -----
From: "Ietf Roll" <[email-masked]>
To: "JP Vasseur" <[email-masked]>, "Thomas Heide Clausen" <[email-masked]>
Cc: "roll WG" <[email-masked]>
Sent: Saturday, September 3, 2011 2:54:25 AM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new	ROLL WG document

JP Vasseur wrote: 

Rav 

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Don Sturek <[email-masked]>
Date: Sun, 04 Sep 2011 06:20:27 -0700

Here are a few points to maybe consider:
1)   ZigBee is not "having problems making it work" (referring to ROLL RPL.
I chair the group in ZigBee testing "ZigBee IP" and we have had relatively
good success using RPL for the use cases we are considering.
2)   The Smart Energy 2.0 use cases are for only 30 devices in a single home
area network.   We are testing 30 nodes with 3 hops
3)   The upward routing feature in RPL is quite efficient.  The downward
routing feature either assumes storing mode (which we don't use) or
non-storing mode with source routing (which does not offer pro-active or
re-active route establishment).
4)   I personally would not use ROLL RPL as it is for low latency
applications like lighting control, home automation, etc.   I fully support
the ROLL RPL P2P draft for these applications.

On additional, perhaps related topics:
5)  I don't believe there will be only a single mesh routing protocol
defined for all applications in IETF.  I fully support the work going on in
MANET and also think "mesh under" solutions will also be useful for some
applications

And finally:
6)  All this said, I think ZigBee IP will successfully conclude testing
using ROLL RPLŠŠŠŠ

Happy to sign my real name,

Don Sturek

From:  Ietf Roll <[email-masked]>
Reply-To:  Ietf Roll <[email-masked]>
Date:  Sat, 3 Sep 2011 00:54:25 -0700 (PDT)
To:  JP Vasseur <[email-masked]>, Thomas Heide Clausen
<[email-masked]>
Cc:  roll WG <[email-masked]>
Subject:  Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new
ROLL WG document

JP Vasseur wrote:

*if* you think that this not elegant enough (which has to be demonstrated
IMO), then you must be supportive
of the P2P IDs work that the WG has been working on ?

[rav] how about a demonstration that RPL actually works as purported.
Thomas has said that his group implemented it and it was difficult, complex
and fraught with inconsistencies in specification.
         I heard that zigbee is having problems making it work and the only
paper that I've seen on RPL says that for constrained nodes they recommend
no more than 30 nodes in a network.  Hardly the scale necessary for some of
the 
         use cases been suggested (like AMI).

         The P2P is a hack to try to fix the fact the RPL is basically a
collection tree and as such downward routing is an distant after thought
(certainly not elegant).

         Without lots of memory, node must use non-storing mode (oh and we
are talking about constrained devices so lots of memory is then
inconsistent) and then routing is up to the root and back down.  Not what
anyone who
         understands routing would consider elegant P2P.

         In the rush to get RPL out of the working group we all were
bamboozled by the chair into believing the draft was actually complete and
the IESG further compounded this error.

         If it were possible to fix things, RPL should be an experimental
draft until such time as there are working interoperable implementations
that are shown to provide the services that were required in the various
Use-case
         drafts - or even just one of them.

         And now we are rushing to generate and publish a marketing document
(called an applicability statement) without having any experience with the
protocol.

         Are we rushing and putting so much pressure and bending the systems
so that this gets published before we find we've built a house of cards and
it comes crashing down.

         This will be really counter productive to the industry and the
Internet (certainly not Thomas's warnings).  When everyone looks at this
mistake and says, why didn't the IETF do its job and exercise proper
engineering, then the ROLL WG
          and the Chairs will be the ones that have hurt the industry and
the Internet.

Rav

_______________________________________________ Roll mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: Ietf Roll <[email-masked]>
Date: Mon, 5 Sep 2011 16:22:39 -0700 (PDT)

This is good news that Zigbee is making it work.  I guess that since your 
requirements are only 30 nodes then that matches the paper that says RPL for constrained devices should be limited to 30 nodes.

It is also good to be re-affirmed that downward routing is not 
particularly good in RPL.  Others have already stated this and Zigbee 
seems to confirm this.

Rav

PS - Since many keep pointing at 
me, I am not putting my full name and company in my email for I fear retribution.  I do not want to lose my job for asking questions and 
criticizing parts of the RPL design.  I do not want my company or my 
supervisor called by people like a chair and have my job put at risk.

________________________________
From: Don Sturek <[email-masked]>
To: Ietf Roll <[email-masked]>; JP Vasseur <[email-masked]>; Thomas Heide Clausen <[email-masked]>
Cc: roll WG <[email-masked]>
Sent: Sunday, September 4, 2011 7:20 AM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Here are a few points to maybe consider:
1)   ZigBee is not "having problems making it work" (referring to ROLL RPL.   I chair the group in ZigBee testing "ZigBee IP" and we have had relatively good success using RPL for the use cases we are considering.
2)   The Smart Energy 2.0 use cases are for only 30 devices in a single home area network.   We are testing 30 nodes with 3 hops
3)   The upward routing feature in RPL is quite efficient.  The downward routing feature either assumes storing mode (which we don't use) or non-storing mode with source routing (which does not offer pro-active or re-active route establishment).
4)   I personally would not use ROLL RPL as it is for low latency applications like lighting control, home automation, etc.   I fully support the ROLL RPL P2P draft for these applications.

On additional, perhaps related topics:
5)  I don't believe there will be only a single mesh routing protocol defined for all applications in IETF.  I fully support the work going on in MANET and also think "mesh under" solutions will also be useful for some applications

And finally:
6)  All this said, I think ZigBee IP will successfully conclude testing using ROLL RPL…………

Don Sturek

To:  JP Vasseur <[email-masked]>, Thomas Heide Clausen <[email-masked]>

JP Vasseur wrote:

*if* you think that this not elegant enough (which has to be demonstrated IMO), then you must be supportive
of the P2P IDs work that the WG has been working on ?
[rav] how about a demonstration that RPL actually works as purported.  Thomas has said that his group implemented it and it was difficult, complex and fraught with inconsistencies in specification.
         I heard that zigbee is having problems making it work and the only paper that I've seen on RPL says that for constrained nodes they recommend
 no more than 30 nodes in a network.  Hardly the scale necessary for some of the 
         use cases been suggested (like AMI).

         In the rush to get RPL out of the working group we all were bamboozled by the chair into believing the draft was actually complete and the
 IESG further compounded this error.

         This will be really counter productive to the industry and the Internet
 (certainly not Thomas's warnings).  When everyone looks at this mistake and says, why didn't the IETF do its job and exercise proper engineering, then the ROLL WG
          and the Chairs will be the ones that have hurt the industry and the Internet.

Rav

_______________________________________________
Roll mailing list [email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: Omprakash Gnawali <[email-masked]>
Date: Mon, 5 Sep 2011 22:41:02 -0500

Can someone post a link to the paper being referenced? Thanks.

- om_p

On Mon, Sep 5, 2011 at 6:22 PM, Ietf Roll <[email-masked]> wrote:
> requirements are only 30 nodes then that matches the paper that says RPL for
> constrained devices should be limited to 30 nodes.
> It is also good to be re-affirmed that downward routing is not particularly
> good in RPL.  Others have already stated this and Zigbee seems to confirm
> this.
>
> Rav
> PS - Since many keep pointing at me, I am not putting my full name and
> company in my email for I fear retribution.  I do not want to lose my job
> for asking questions and criticizing parts of the RPL design.  I do not want
> my company or my supervisor called by people like a chair and have my job
> put at risk.
> using ROLL RPL…………

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 5 Sep 2011 21:51:52 -0700

Omprakash,

I believe the paper he refers to is that:
J. Ko, S. Dawson-Haggerty, O. Gnawali, D. Culler, A. Terzis, "Evaluating the
Performance of RPL and 6LoWPAN in TinyOS"
http://hinrg.cs.jhu.edu/joomla/images/stories/TinyRPL.pdf

Omprakash, you are an author of that paper :-)

The paper states: "In our experiments with downstream routing in storing
mode, we noticed that the current TinyRPL/BLIP implementations on TelosB
motes support up to ∼30 target destinations. This argues that to support
routes to all nodes in the RPL network, the network’s size must be limited
to ∼30 nodes."

Regards
Ulrich

On Mon, Sep 5, 2011 at 8:41 PM, Omprakash Gnawali
<[email-masked]>wrote:

> particularly
> > To: Ietf Roll <[email-masked]>; JP Vasseur <[email-masked]>; Thomas
> Heide
> > Clausen <[email-masked]>

---

From: C Chauvenet <[email-masked]>
Date: Tue, 6 Sep 2011 00:40:22 -0700

Hi,

Thank you for the link.

As mentioned in the sentence, this is related to the TinyRPL/BLIP implementation of RPL runing on TelosB nodes.
TelosB offers 48K of ROM and 10K of RAM.
As far as I understand, the 30 nodes limitation is related to the TelosB architecture (RAM size in particular) and not RPL.
Because TelosB has been designed in 2004, we can expect that platforms used for RPL deployments of today may have quite different characteristics.

Author may complete my understanding.

Cédric.

De : [email-masked] [mailto:[email-masked]] De la part de Ulrich Herberg
Envoyé : mardi 6 septembre 2011 06:52
À : Omprakash Gnawali
Cc : roll WG
Objet : Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Omprakash,

I believe the paper he refers to is that:
J. Ko, S. Dawson-Haggerty, O. Gnawali, D. Culler, A. Terzis, "Evaluating the Performance of RPL and 6LoWPAN in TinyOS"
http://hinrg.cs.jhu.edu/joomla/images/stories/TinyRPL.pdf

The paper states: "In our experiments with downstream routing in storing mode, we noticed that the current TinyRPL/BLIP implementations on TelosB motes support up to ∼30 target destinations. This argues that to support routes to all nodes in the RPL network, the network’s size must be limited to ∼30 nodes."

Regards
Ulrich
On Mon, Sep 5, 2011 at 8:41 PM, Omprakash Gnawali <[email-masked]<mailto:[email-masked]>> wrote:
Can someone post a link to the paper being referenced? Thanks.

- om_p

On Mon, Sep 5, 2011 at 6:22 PM, Ietf Roll <[email-masked]<mailto:[email-masked]>> wrote:
> From: Don Sturek <[email-masked]<mailto:[email-masked]>>
> To: Ietf Roll <[email-masked]<mailto:[email-masked]>>; JP Vasseur <[email-masked]<mailto:[email-masked]>>; Thomas Heide
> Clausen <[email-masked]<mailto:[email-masked]>>
> Cc: roll WG <[email-masked]<mailto:[email-masked]>>
> From: Ietf Roll <[email-masked]<mailto:[email-masked]>>
> Reply-To: Ietf Roll <[email-masked]<mailto:[email-masked]>>
> To: JP Vasseur <[email-masked]<mailto:[email-masked]>>, Thomas Heide Clausen
> <[email-masked]<mailto:[email-masked]>>
> Cc: roll WG <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/roll
>
>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Omprakash Gnawali <[email-masked]>
Date: Fri, 9 Sep 2011 23:07:01 -0500

On Tue, Sep 6, 2011 at 2:40 AM, C Chauvenet <[email-masked]> wrote:
> Hi,
>
>
>
> Thank you for the link.
>
>
>
> As mentioned in the sentence, this is related to the TinyRPL/BLIP
> implementation of RPL runing on TelosB nodes.
>
> As far as I understand, the 30 nodes limitation is related to the TelosB
> architecture (RAM size in particular) and not RPL.
>
> Because TelosB has been designed in 2004, we can expect that platforms used
> for RPL deployments of today may have quite different characteristics.
>
>
>

Thank you for sharing the paper and also your commentary.

We should be concerned about the state requirement of the storing
mode. However, we should not extrapolate these results too far beyond
the constraints we worked with in our experiments.

- om_p

---

From: Stephen Dawson-Haggerty <[email-masked]>
Date: Sat, 10 Sep 2011 15:32:19 +0000

I implemented most of the parts that are limited to 30, and I believe it
could certainly be improved even with telosb-style memory.  RPL table size
is only one limiting factor at the moment, there are also packet buffers
which could be either shrunk or differently managed.  Furthermore, at the
cost of a little more code space we could easily compress the routing table
-- right now we store full destination addresses and next hops but these
often share a common prefix, usually /112 if short addresses are in use.

Steve

On Tue, Sep 6, 2011 at 12:40 AM, C Chauvenet <[email-masked]>wrote:

> Hi, ****
>
> ** **
>
> Thank you for the link.****
>
> ** **
>
> implementation of RPL runing on TelosB nodes. ****
>
> TelosB offers 48K of ROM and 10K of RAM.****
>
> architecture (RAM size in particular) and not RPL.****
>
> for RPL deployments of today may have quite different characteristics.****
>
> ** **
>
> Author may complete my understanding.****
>
> ** **
>
> Cédric.****
>
> ** **
>
> *De :* [email-masked] [mailto:[email-masked]] *De la part de
> * Ulrich Herberg
> *Envoyé :* mardi 6 septembre 2011 06:52
> *À :* Omprakash Gnawali
> *Cc :* roll WG
> *Objet :* Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new
> ROLL WG document****
>
> ** **
>
> Omprakash,
>
> J. Ko, S. Dawson-Haggerty, O. Gnawali, D. Culler, A. Terzis, "Evaluating
> the Performance of RPL and 6LoWPAN in TinyOS"
> Ulrich****
> On Mon, Sep 5, 2011 at 8:41 PM, Omprakash Gnawali <[email-masked]>
> wrote:****
>
> - om_p****
> >****
> > _______________________________________________****
>
> > Roll mailing list
> > [email-masked]
> >****
> _______________________________________________****
>
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll****
>
> ** **
>

-- 
stephen dawson-haggerty
http://cs.berkeley.edu/~stevedh
uc berkeley wireless and embedded systems lab
berkeley, ca 94720

---

From: Philip Levis <[email-masked]>
Date: Sat, 10 Sep 2011 14:24:55 -0700

On Aug 31, 2011, at 10:08 AM, Thomas Heide Clausen wrote:

> 
> On Aug 31, 2011, at 19:05 , JP Vasseur wrote:
> 
>> 
>> On Aug 31, 2011, at 6:57 PM, Thomas Heide Clausen wrote:
>> 
>>> 
>>> On Aug 31, 2011, at 18:41 , JP Vasseur wrote:
>>> 
>>> >
>>> > On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote:
>>> >
>>> >> I would actually argue that RPL and P2P-RPL are two entirely different protocols (albeit sharing some commonalities in the overall message structure).
>>> >>
>>> >> There are ways of making multiple routing protocols co-exist on the same routers (and in the same network). However I am not sure that it is such  a good idea to do so in a LLN.
>>> >>
>>> >> I've always found it odd that P2P traffic was not supported in RPL -- and really, dog-leg routing through a DODAG root and using source routing isn't (efficiently) supporting P2P.
>>> >
>>> > Thomas,
>>> >
>>> > I cannot let you say this … you perfectly know that the core specification of RPL supports P2P traffic.
>>> 
>>> Ah, but you must, JP, you must.
>>> 
>>> Note that I said in the above that RPL supports P2P traffic by way of dog-leg routing through the DODAG root, then source routing -- that's the _only_ way P2P is supported, guaranteed to work across all the different RPL-flavors (storing/non-storing with/without RPL-P2P, …) that the WG is exploring.
>>> 
>> Well the sentence was, to say the least, strangely worded … As you know, you go via the root only if you deploy non-storing.
>> 
> 
> Well, given the state requirements for storing-mode in networks larger than a few handful of routers, non-storing mode seems to be the only realistic choice for the lions share of deployments that I am aware of. 
> 
> Thus, dog-leg-source-routing is pretty much the only viable option - and you must admit that it's not a particularly elegant or efficient option at that?

Thomas,

In the mesh space, I'm less concerned with "elegant," which is based on taste and mental conception, than "works," which means it's practical and actually solves problems. You know as well as I do how wireless mesh research (and even proposed standards!) is a graveyard of elegant solutions which don't work.  

Up-down routing may not be very efficient in the data plane, it's true: but it has significant benefits in terms of the size and cost of maintaining routing tables, in terms of RAM, state management complexity, and control traffic. There are plenty of deployments today which use it because it's simple and practical. From the perspective of an elegant idea for the academy, it's not very appealing; but I trust the engineers I've spoken with on how attractive it is as a practical solution. It's clear that if P2P traffic between nodes distant from roots is the dominant traffic pattern, one might want something more efficient (hence the P2P work); but many networks are simpler data collection networks with smaller amounts of P2P traffic, and ignoring their needs seems mistaken to me.

Phil