Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences

[Ulrich Herberg <[e-mail]>]

Dear Mukul,

thank you for your review. Please find my comments below:

On Mon, May 21, 2012 at 8:45 AM, Mukul Goyal <[e-mail]> wrote:
> Here is my review for first 9 sections of draft-clausen-lln-rpl-experiences-03. For later sections, I have nothing substaintial to add to what Philip has already said in the message below.
>
> One answer to many questions raised in draft-clausen is: use P2P-RPL.

In previous email exchanges, it has been argued why we believe this is
insufficient (P2P-RPL not officially "updating" or "obsoleting" RPL,
and not being Std. Track etc). (see here:
http://www.ietf.org/mail-archive/web/roll/current/msg07005.html)


> It is not the case that P2P-RPL must always be used simply because the problems it solves are not significant in all scenarios or application domains. But, where it makes sense, P2P-RPL can certainly be used. P2P-RPL is currently aiming for Experimental status. As more experience is gained with its operation, it will go for Standards Track status.



Again, such a Std. Track document may be published in several years,
but until then, commercial deployments of RPL routers will be based on
current specifications.



>
> Thanks
> Mukul
>
> Section 4: Requirement Of DODAG Root
> --------------------------------------
>
> "RPL Routers provisioned with resources to act as DODAG Roots, and
>   administratively configured to act as such, represent a single point
>   of failure in the network.  As the memory requirements for the DODAG
>   Root and for other RPL Routers are substantially different, unless
>   all RPL Routers are provisioned with resources (memory, energy, ...)
>   to act as DODAG Roots, effectively if the designated DODAG Root
>   fails, the network fails and RPL is unable to operate.  Even if
>   electing another RPL Router as temporary DODAG root (e.g., for
>   forming a "Floating" DODAG) for providing internal connectivity
>   between RPL Routers, this router may not have the necessary resources
>   to satisfy this role as (temporary) DODAG Root.
> "
>
> If a deployment uses "RPL + P2P-RPL", the criticism listed above is not valid. There is no single point of failure. If the global DAG(s) cannot work because of the root's failure, the nodes can still discover routes to each other using P2P-RPL. Nodes do not need extra memory/CPU to run P2P-RPL.


See our arguments from previous emails about P2P-RPL
(http://www.ietf.org/mail-archive/web/roll/current/msg07005.html)



> "Another possible LLN scenario is that only internal point-to-point
>   connectivity is sought, and no RPL Router has a more "central" role
>   than any other - a self-organizing LLN.  Requiring special
>   provisioning of a specific "super-node" as DODAG Root is both
>   unnecessary and undesirable."
>
> Such an LLN can just use P2P-RPL. No need for special provisioning for any node.


See our arguments from previous emails about P2P-RPL
(http://www.ietf.org/mail-archive/web/roll/current/msg07005.html)



> Section 5:  RPL Data Traffic Flows
> --------------------------------------
>
> " RPL makes a-priori assumptions of data traffic types, and explicitly
>   defines three such [I-D.ietf-roll-terminology] traffic types: sensor-
>   to-root data traffic (multipoint-to-point) is predominant, root-to-
>   sensor data traffic (point-to-multipoint) is rare and sensor-to-
>   sensor (point-to-point) data traffic is extremely rare.  While not
>   specifically called out thus in [RFC6550], the resulting protocol
>   design, however, reflects these assumptions in that the mechanism
>   constructing multipoint-to-point routes is efficient in terms of
>   control traffic generated and state required, point-to-multipoint
>   route construction much less so - and point-to-point routes subject
>   to potentially significant route stretch (routes going through the
>   DODAG Root in non-storing mode) and over-the-wire overhead from using
>   source routing (from the DODAG Root to the destination) (see
>   Section 7) - or, in case of storing mode, considerable memory
>   requirements in all LLN routers inside the network (see Section 7).
> "
>
> P2P-RPL resolves any route stretch issues.


See our arguments from previous emails about P2P-RPL
(http://www.ietf.org/mail-archive/web/roll/current/msg07005.html)


> Note that if the source and destination are far apart, the route stretch with core RPL is not much (i.e. the along-DAG routes wont be much worse than direct routes) although the constraint to traverse through the root may still cause congestion near the root. If source and destination are nearby, the route stretch with "along global DAG" route could be significant and that is where using P2P-RPL makes most sense.
>
> Also, P2P-RPL supports discovery of both hop-by-hop routes and source routes. A source could choose which one to use for a particular destination.
>
> "The data traffic characteristics, assumed by RPL, do not represent a
>   universal distribution of traffic types in LLNs:
>
>   o  There are scenarios where sensor-to-sensor traffic is a more
>      common occurrence, documented, e.g., in [RFC5867] ("Building
>      Automation Routing Requirements in Low Power and Lossy Networks").
>
> "
>
> And in such cases, it makes sense to use P2P-RPL with or without core RPL.
>
> "For the former, all sensor-to-sensor routes include the DODAG Root,
>   possibly causing congestions on the communication medium near the
>   DODAG Root, and draining energy from the intermediate RPL Routers on
>   an unnecessarily long route.  If sensor-to-sensor traffic is common,
>   RPL Routers near the DODAG Root will be particularly solicited as
>   relays, especially in non-storing mode.
> "
>
> Use P2P-RPL.

See our arguments from previous emails about P2P-RPL
(http://www.ietf.org/mail-archive/web/roll/current/msg07005.html)



> Section 6:  Fragmentation Of RPL Control Messages And Data Packet
> ----------------------------------------------------------------
> " While 79 octets
>   may seem to be sufficient to carry RPL control messages, consider the
>   following: RPL control messages are carried in ICMPv6, and the
>   mandatory ICMPv6 header consumes 4 octets.  The DIO base another 24
>   octets.  If link metrics are used, that consumes at least another 8
>   octets - and this is using a hop count metric; other metrics may
>   require more.  The DODAG Configuration Object consumes up to a
>   further 16 octets, for a total of 52 octets.  Adding a Prefix
>   Information Object for address configuration consumes another 32
>   octets, for a total of 84 octets - thus exceeding the 79 octets
>   available for L3 data payload and causing link-layer fragmentation of
>   such a DIO. "
>
> It is certainly possible for a DIO to exceed 79 bytes. But, it is not the case that a DIO would always fragment.

Likely not, but several of these options need to be frequently
included (such as link metric options, and DODAG Configuration options
+ Prefix Information options for use in dynamic topologies where new
routers may join the RPL instance).

More importantly, fragmentation on the data layer is the bigger issue,
since that is out of control of the routing protocol, and may lead to
loss of data packets.



> DODAG Configuration Option is an "option" and so is the Prefix Information Option. Every DIO need not carry these options (or others defined in Section 6.7 of RPL RFC).




>
> That being said, possible fragmentation of DIOs is a real issue. When designing a packet format, one always has to struggle to achieve a balance between the need to save space and the need to be modular - two conflicting goals. Pascal called the P2P Route Discovery Option (P2P-RDO, defined in P2P-RPL) a "garbage can option" because it includes all the information P2P-RPL route discovery needs (besides what is carried in the configuration option, the metric containers and the DIO base object). We designed P2P-RDO thinking that the need to save space is more critical. Various options defined in RPL RFC were designed giving more importance to the need for modularity. I dont think this is necessarily a bad thing as draft-clausen alleges.


We did not allege that this "is a bad thing", we simply made an
observation that control and data packets may be fragmented when using
RPL.


> While many RPL deployments will use IEEE 802.15.4 as the link layer in near future, this may not always be the case. The correct solution to the problem of fragmentation in 802.15.4 LLNs is to devise a compression mechanism at 6lowpan level. Some
>  thing similar to draft-bormann-6lowpan-ghc-04 or the RPL-specific compression scheme we proposed (draft-goyal-roll-rpl-compression but now working at 6lowpan layer).

We don't know how 6lowpan compression could alleviate the
fragmentation issues we observe in draft-clausen-lln-rpl-experiences.
We already consider compressed addresses in our draft.

As discussed at the IETF when draft-goyal-roll-rpl-compression was
presented, it was noted that such a mechanism would lead to
non-interoperable implementations of RPL. Since there are already
commercial RPL routers out in the market, we believe that is not a
good proposal.

>
> "As a point of reference, the ContikiRPL [rpl-contiki]
>   implementation includes both the DODAG Configuration option and the
>   Prefix Information option in all DIO messages.  Any other options,
>   e.g., Route Information options indicating prefixes reachable through
>   the DODAG Root, increase the overhead and thus the probability of
>   fragmentation.
> "
>
> OK, so a particular implementation always includes config and PI options in all DIOs. That sounds like a problem this particular implementation has created for itself.

True, but there are no clear guidelines in the RPL specification how
to do better (see also section 12 of our draft). Considering that
ContikiRPL is one of the most wide-spread open-source implementations
of RPL, it may be an indication that implementers may do bad choices
based on reading the specification.


>
> "Given the minimal packet size of LLNs, the routing protocol must
>   impose low (or no) overhead on data packets, hopefully independently
>   of the number of hops [RFC4919].  However, source-routing not only
>   causes increased overhead in the IP header, but also leads to a
>   variable available payload for data (depending on how long the source
>   route is)."
>
> Again, this is not a simple one-sided issue. Yes, source routes eat precious bytes in the data packets. But, in many constrained environments (e.g. in some home automation deployments), only source routing is possible because devices are hard pressed for memory and cannot maintain any routing state.


But still, the problems we describe for source routes may occur.



> "In point-to-point communication and when non-storing mode
>   is used for downward traffic, the source of a data packet will be
>   unaware of how many octets will be available for payload (without
>   incurring L2.5 fragmentation) when the DODAG Root relays the data
>   packet and add the source routing header.  Thus, the source may
>   choose an inefficient size for the data payload: if the data payload
>   is large, it may exceed the link-layer MTU at the DODAG Root after
>   adding the source-routing header; on the other hand, if the data
>   payload is low, the network resources are not used efficiently, which
>   introduces more overhead and more frame transmissions.
>
> "
>
> This is a good point to make. Note that this problem is not present when the source (rather than the DAG root) itself includes the source route in the packet. So, this problem goes away when using P2P-RPL.


See our arguments from previous emails about P2P-RPL
(http://www.ietf.org/mail-archive/web/roll/current/msg07005.html)



>
> Section 7: The DAO Mechanism: Downward and Point-to-Point Routes
> ---------------------------------------------------------------
>
> "RPL specifies two distinct and incompatible "modes of operation" for
>   downward traffic: storing mode, where each RPL Router is assumed to
>   maintain routes to all destinations in its sub-DODAG, i.e., RPL
>   Routers that are "deeper down" in the DODAG, and non-storing mode,
>   where only the DODAG Root stores routes to destinations inside the
>   LLN, and where the DODAG Root employs strict source routing in order
>   to route data traffic to the destination RPL Router.
> "
>
> The above description of storing mode is incorrect. It is not the case that, in storing mode, each RPL Router maintains routes to all destinations in its sub-DODAG. The child decides which of its parents would receive a DAO. Further, for each advertized destination, the origin (of the advertisement) decides (via path control bits) how many separate routes could exist for this destination.

Yes, but still each child has to be advertised by at least one DAO
parent (and therefore all children and grandchildren etc. are stored
on DAO parents). The Path Control bits may be used to select more than
one parallel path to a target, which would even increase the state
requirements.

>
> Section 7.1:
>
> "In case a destination is
>   unreachable, all the DODAG Root may do is require all destinations to
>   re-issue their DAOs, by way of issuing a DIO with an increased DODAG
>   version number, possibly provoking a broadcast-storm-like situation.
> "
>
> This problem is easily fixable by a simple DAO solicitation mechanism: root includes a solicitation in its DIO, routers in the DAG propagate the solicitation further in their DIOs and when the desired destination receives the solicitation, it sends the DAO to the root. Pascal has often talked about writing up this fix.


Something like this may be an option, but it is not part of the RPL
specification, which is exactly what our draft observes.


>
> "A final point on the DAO mechanism: RPL supports point-to-point
>   traffic only by way of relaying through the DODAG.  In networks where
>   point-to-point traffic is no rare occurrence, this causes unduly long
>   routes (with possibly increased energy consumption, increased
>   probability of packet losses) as well as possibly congestion around
>   the DODAG Root.
> "
>
> Use P2P-RPL in such scenarios.

See our arguments from previous emails about P2P-RPL
(http://www.ietf.org/mail-archive/web/roll/current/msg07005.html)


>
> Section 8: Address aggregation and summarization
> ------------------------------------------------------
> I dont agree with the assertion that address aggregation will break down completely if a node's DAO parent is not same as the one whose advertized prefix was used by the node to configure its address. I think DAO parent selection at lower levels wont have too much impact on address aggregation at nodes at upper level. Sure address aggregation may not be possible at the node's parent or grandparent. But, nodes still higher up will be less and less affected.


Yes, if you use a hierarchical aggregation, then this may be true.
But, as we observe in our draft, there is no such mechanism specified
which guarantees correct topological aggregation in dynamic networks.
Moreover, in networks where 6lowpan compressed addresses are used,
aggregation may not be possible.



>
> Also, there might be factual inaccuracy in the text below.
>
> " Any aggregated routes require the use of a prefix shorter than /64,
>   and subsequent hierarchical assignment of prefixes down to a /64 (as
>   any RPL Router itself provides a /64 subnet to any hosts connected to
>   the router).
>
>   Moreover, if the 6lowpan adaption layer [RFC4944] is used in the LLN,
>   route aggregation is not possible since the same /64 is applied
>   across the entire network."
>
> I dont think an RPL router has to always advertize a 64 bit prefix to its hosts.

RFC4291 states:
"For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format."

> Further, with RFC 6282, I am not sure if only /64 prefix could be used for autoconfiguration of 802.15.4 interfaces.


Can you precise how autoconfiguration could use other prefix lengths
when using RFC6282? Either hosts may be attached to RPL routers, in
which case each RPL router needs to be assigned a 64 bit prefix, or
6lowpan compressed addresses are used, in which case I don't know how
address aggregation could be done in the network (since all routers
use the same prefix in the lowpan).



> So, the assertion "Any aggregated routes require the use of a prefix shorter than /64" may not be true.
>
> Section 9: Link assumed bidirectional
> -------------------------------------------------
>
> "Unidirectional links are no rare occurrence, such as is known from
>   wireless multi-hop networks.  Preliminary results from a test-bed of
>   AMI (Automated Metering Infrastructure) devices using 950MHz radio
>   interfaces, and with a total of 22 links, show that 36% of these
>   links are unidirectional."
>
> Could the authors provide reference to published literature showing that a significant fraction of links are unidirectional? The reference to an unpublished/unavailable study is not OK. Also, it seems that "950MHz" is a typo.

Experience from many years in MANETs have told us that links tend to
be highly asymmetric to the point of being unidirectional. Do you have
a different experience? Why is 950MHz a typo?

Best regards
Ulrich and Jiazi


>
> ----- Original Message -----
> From: "Philip Levis" <[e-mail]>
> To: "Thomas Heide Clausen" <[e-mail]>
> Cc: "roll WG" <[e-mail]>, "Michael Richardson" <[e-mail]>
> Sent: Thursday, May 17, 2012 12:02:32 AM
> Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences
>
>
> On May 16, 2012, at 10:11 AM, Thomas Heide Clausen wrote:
>
>>
>>
>> For example:
>>
>>       o       the state required for storing/non-storing mode does *not* depend on a
>>               specific implementation and deployment, but is an artifact from the RPL design.
>>
>>       o       the message-size of RPL is not dependent on a specific implementation and deployment,
>>               but is an artifact from the RPL design.
>>
>>       o       the use of links "upwards" based on receipt of traffic "downwards" (i.e. the unidirectional
>>               link issue) is not dependent on a specific implementation and deployment,
>>               but is an artifact from the RPL design.
>>
>>       o       the unknown-by-source MTU issues for data-traffic when using non-storing mode
>>               is not dependent on a specific implementation and deployment,
>>               but is an artifact from the RPL design.
>>
>> I could go on, but then it'd be easier to just paste the whole I-D into this email.
>
>
> Thomas,
>
> I agree that some points in the ID are valid statements about the protocol itself, such as message sizes and the issues caused by floating DODAGs. Those, to me, seem like reasonable points to make.
>
> However, some of the points are hypotheses about performance (14), a bit naive about how wireless networks behave (13) or somewhat snippy gripes (11, 12). In my opinion, a document which focused on factual statements of the protocol design not really open to interpretation and cut hypothetical or subjective statements might be ready for the working group to consider.
>
> As just a start, I object to 10, 11, 12, 13, and 14 being considered inherent to the protocol.
>
> 10 assumes that a node only uses DIO reception to allow a parent; the specification is pretty clear that you should check the parent is usable (section 1.1). You're taking a bad implementation decision and assuming there isn't another way to do things.
>
> For 11, there are implementations of RPL smaller than 50kB; they do not implement every feature, but that was kind of the point of the protocol, that it could be implemented on a sliding scale of implementation complexity. The TinyOS implementation, for example, is, I believe, ~20kB, less than half the size. You don't report what architecture the 50kB is for, clearly it would be more for a 32-bit than a 16-bit architecture.
>
> For 12, "implementations may exhibit a bad performance if not carefully implemented."  I think it is safe to say this is true for almost ANY protocol. A specification is not intended to be a complete statement of efficient implementation, otherwise you give little latitude to future improvements and good engineering.
>
> For 13, this assumes that a wireless network has a stable topology which the protocol can converge to. Wireless networks are often NOT stable: one cannot expect a protocol to converge on a dynamic graph.
>
> 14 is similarly confused about what a wireless network looks like. How can the state of a distributed system based on a dynamic topology be "consistent?" I think this is a fundamental misunderstanding of how the network works.
>
> That being said, I think point 6 is well taken and should be considered, maybe others. Maybe the constructive way to take this document, if you don't want to take the step of specifying solutions, is at least casting it as a roadmap for ways in which you think the WG should improve RPL?
>
> Phil
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll