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

[Stephen Dawson-Haggerty <[e-mail]>]

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 <[e-mail]>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. ****
>
> 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 :* [e-mail] [mailto:[e-mail]] *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
>
> 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 <[e-mail]>
> 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 <[e-mail]> wrote:
> > 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 <[e-mail]>
> > To: Ietf Roll <[e-mail]>; JP Vasseur <[e-mail]>; Thomas
> Heide
> > Clausen <[e-mail]>
> > Cc: roll WG <[e-mail]>
> > 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…………
> > Happy to sign my real name,
> > Don Sturek
> >
> >
> >
> > From: Ietf Roll <[e-mail]>
> > Reply-To: Ietf Roll <[e-mail]>
> > Date: Sat, 3 Sep 2011 00:54:25 -0700 (PDT)
> > To: JP Vasseur <[e-mail]>, Thomas Heide Clausen
> > <[e-mail]>
> > Cc: roll WG <[e-mail]>
> > 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
> > [e-mail] https://www.ietf.org/mailman/listinfo/roll
> >
> >****
>
> > _______________________________________________****
>
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> >
> >****
>
> _______________________________________________****
>
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll****
>
> ** **
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> 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