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

[Ulrich Herberg <[e-mail]>]

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
>