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

From: Thomas Heide Clausen <[email-masked]>
Date: Sun, 3 Jun 2012 16:25:24 -0700

Dear  JP,

Opaque LSAs are an interesting, although entirely irrelevant, example - an apples-to-oranges comparison. 

Opaque LSAs are simply "containers for application specific data, for distribution through an OSPF domain (link, area, AS wide)". As such, it's - of course - difficult to specify a transmission frequency; I am sure that we agree that this naturally is an application dependent issue.

DAOs are much more akin to OSPF HELLO or LSA packets, in that they pertain to distributing topology proper for the routing protocol operation - specifically, DAOs are not the slightest like opaque LSAs. OSPF does quite specify expectations for when, for example, a HELLO packet should have been received (RouterDeadInterval / InactivityTimer) or LSAs re-flooded (LSRefreshTime).

In other words, for opaque LSAs, the content of the LSA is opaque to the routing protocol (could be anything), whereas the dissemination process is well defined. Contrast with DAO, where the content is known (and very much important to the routing protocol), alas, the processing and dissemination is opaque and so you need an external mechanism for DAO to work properly.

I also note a different point, which is that the environment wherein an OSPF router generally operates (accessible, network engineer access during operation) is very different from the environment wherein an RPL router is expected to operate.

Finally, there are protocols, typically those designed for non-managed deployments. which permit routers with different parameter configurations to interoperate, and then again others where lack of needed information can simply trigger a request for it to be generated.

Concluding: thus comparing with an information type for a different purpose, extracted from a protocol for a different deployment with constraints of a different nature doesn't really help.

Best,

Thomas

On May 19, 2012, at 12:39 , JP Vasseur wrote:

> Hi Martin,
> 
> co-chair hat off …
> 
> How often do you think that ISIS LSA should be refreshed ?
> Or OSPF opaque LSA for TE extensions be flooded ?
> Or BFD packets ? 
> Or PCEP Keepalive when turned on ?
> 
> Very seriously … these questions apply to all protocols … and you cannot expect the specifications to give you
> hard coded values (but default whenever possible); these are topology and application specific, don't you think ?
> 
> Thanks.
> 
> Cheers.
> 
> JP.
> 
> On May 18, 2012, at 10:46 PM, Martin Heusse wrote:
> 
>> Phil, 
>> what you are writing bellow may be true (although...) but it does not address comment 12, that we have no idea when DAOs should be sent and how DAOs should be handled (how long should the route be kept?). 
>> 
>> Along those lines, 2 comments:
>> 1) I notice that draft-ietf-roll-applicability-ami, for instance, ignores DAOs except for specifying that DAOs SHOULD be sent -- so they might not be sent--, even though "Two-way communication is a requirement"(?). At the same time, this draft goes as far as suggesting what parameters to use for trickle (big deal) or for MaxRankIncrease (big deal: will things break if someone uses 512 instead of 1024?). 
>> (same comment applies to draft-gnawali-roll-rpl-recommendations-03.)
>> 2) <sarcasm> What is the point of making DAOs compact in storing mode (learning the route recursively) while the packets that actually contain data have to carry the whole path anyway? </sarcasm> 
>> 
>> Best regards,
>> Martin
>> 
>> 
>> Philip Levis wrote:
>> 
>>> 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.
>> 
>> _______________________________________________
>> Roll mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sun, 3 Jun 2012 17:27:34 -0700

Dear Phil,

Thank you for your review. Comments below (with apologies for the incurred delay).

On May 16, 2012, at 22:02 , Philip Levis wrote:

> 
> 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.

Thank you, we appreciate this.
> 
> 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.
> 

Very good, this gives us precise points to discuss technically, and we want to thank you for having been so precise and constructive in your email on this subject.

> 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. 
> 

That is definitely a fair point to bring up.

We agree that various external mechanisms can contribute to make a smart, or even very smart, parent selection - but, as section 1.1 points out, as bi-directional links are a minimum requirement, the fact that RPL doesn't specify a minimum, basic mechanism for ensuring that is highly problematic. NUD is the only mechanism explicitly called out in RPL (section 8.2, 9.8, for example), which is why the observations in section 10 concern RPL when using NUD (and not some other "good (but unspecified) design decision").

We do, however, understand (but correct us if we are wrong) that you agree that the mechanisms for this problem, as specified in the RPL RFC, are insufficient for building and operating networks. That is exactly the point that we are trying to make also.

Where we may differ in opinion (do we?)  is, that we think that the IETF should specify such mechanisms: in order to make interoperable implementations, some sort of agreement on what a "good implementation decision" is required, in particular if such requires messages being exchanged.

> 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. 

Phil, would you clarify this for us? 

As the specification reads, there is only the MOP flag that can specify that which the DODAG root expects from the routers in the network; if a router receives a MOP flag that it doesn't support, it won't be able to join as anything as a leaf.

There are no negotiations, or discovery of capabilities, we think, nor is it clear what exactly the "sliding scale"  you refer to is. (sure, we can see the MOP-scale: DIO only, DAO-nonstoring, DAO-storing - but beyond that, what do we miss?)

Short of heavy-handed administrative configuration, the only realistic way of ensuring interoperability of devices from different vendors is to support the full spec.

But, don't just take our words for complexity issues:

	http://comments.gmane.org/gmane.os.contiki.devel/12102

The implementation that we cite (URL is in the draft) is the ContikiRPL implementation, which only supports storing mode, and which consumes these ~50 KB (in the above link, they talk about 44KB being their code size). This on a 16bit MSP 430 tmote sky.

> 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.

We think we get your point, and this phrase is indeed a little like "You can write Fortran77 in any language" ;)

> A specification is not intended to be a complete statement of efficient implementation, otherwise you give little latitude to future improvements and good engineering.

This is very true, and we agree that a specification should (necessarily) be indicating the most efficient way of doing something. 

Alas, for example, for DAO messages, as the diffusion mechanism is not well specified, this may lead to  not just inefficiency, but actual traffic loss by way of connectivity not being accurately reflected in the information sets on RPL, in very mechanical way. 

It would, of course, be perfectly fine to specify an inefficient - but working - method, and allow future improvements and good engineering to better that. Unfortunately, in this case, no working diffusion method is given (i.e., it may lead to the above issues).

In addition, it is not just about efficient implementation from one vendor that could mitigate these problems, but rather about allowing for interoperable implementations in the same routing domain.

> 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.

That it absolutely correct. This observation absolutely applies to the testbed, in which these trickle experiments were conducted.

The point we want to make here is, that contrary to what we observe in simulations and modeling, when deploying trickle in wireless networks, one should expect more control traffic than seen in theory and simulations. We may be able to do an editorial pass to make this section clearer -- especially as it seems that we do agree on the fundamental property that's being discussed?

> 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.

We are a little unclear on what you mean here, or what you suggest that we disagree on. Is it the use of "inconsistent" in the penultimate paragraph of  page 24? 

The purpose is to indicate some of the situations where loops can occur in RPL, and what the consequences hereof, and of the proposed detection mechanisms, are - especially the requirement for IPv6-in-IPv6 tunneling at each hop (which, btw., is independent of if wireless or not).

Thank you again, and we hope that you can clarify the issues that we indicated above.

Best,

Thomas, Ulrich, Jiazi, Axel

> 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
>

---

From: Ulrich Herberg <[email-masked]>
Date: Sun, 3 Jun 2012 19:24:18 -0700

Dear Mukul,

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

On Mon, May 21, 2012 at 8:45 AM, Mukul Goyal <[email-masked]> 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" <[email-masked]>
> To: "Thomas Heide Clausen" <[email-masked]>
> Cc: "roll WG" <[email-masked]>, "Michael Richardson" <[email-masked]>
> Sent: Thursday, May 17, 2012 12:02:32 AM
> Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences
>
>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 4 Jun 2012 07:48:15 +0200

Hi Thomas,

See below-

On Jun 4, 2012, at 1:25 AM, Thomas Heide Clausen wrote:

> DAOs are much more akin to OSPF HELLO or LSA packets,

JP> I gave several examples … such as BFD packets, PCEP Keepalive; the point that I was making is that any protocol, you cannot 
expect to provide hard coded value for the timers in the specifications, it depends of what you are trying to achieve.

Thanks.

JP.

> in that they pertain to distributing topology proper for the routing protocol operation - specifically, DAOs are not the slightest like opaque LSAs. OSPF does quite specify expectations for when, for example, a HELLO packet should have been received (RouterDeadInterval / InactivityTimer) or LSAs re-flooded (LSRefreshTime).
>

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 4 Jun 2012 01:33:39 -0500 (CDT)

>the point that I was making is that any protocol, you cannot 

I agree with JP. Such values may differ not only across applications but also across various deployments within an application domain. I guess the applicability statements might provide some guidance in this respect.

Thanks
Mukul  

----- Original Message -----
From: "JP Vasseur" <[email-masked]>
To: "Thomas Heide Clausen" <[email-masked]>
Cc: "roll WG" <[email-masked]>, "Michael Richardson" <[email-masked]>
Sent: Monday, June 4, 2012 12:48:15 AM
Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences

Hi Thomas,

See below-

Thanks.

JP.

---

From: Philip Levis <[email-masked]>
Date: Wed, 6 Jun 2012 07:25:50 -0700

Responses inline.

> Where we may differ in opinion (do we?)  is, that we think that the IETF should specify such mechanisms: in order to make interoperable implementations, some sort of agreement on what a "good imple…

In the abstract, I agree -- the IETF should specify such mechanisms (assuming their specification is needed for interoperability). However, I think you're taking a dubious philosophical position which is contrary to all other IETF specifications. No RFC specifies every single detail of implementation in its entirety. There seems to be a pull for this from the industrial side, and it's completely mistaken. If we specify everything immediately, in some cases we will be forced to make decisions with very limited information and some of those decisions will be bad. Take a look at the early ZigBee standards. An RFC is not an implementer's guide: it's a tension between clarity and flexibility, so that we can continue to produce interoperable implementations with increasingly better techniques and algorithms. TCP is a canonical example of this.

In that way, I think your draft, as currently written, is disingenuous. I'm sure I could point out plenty of similar examples in OLSR, or OLSRv2, or almost any other IETF specification of non-trivial complexity. This concern or criticism is not specific to RFC6550, but to the RFC process and the notion of an RFC itself. I'm open to having such a debate, but my guess is that your position would collapse once you consider the implications of applying it generally. 

> There are no negotiations, or discovery of capabilities, we think, nor is it clear what exactly the "sliding scale"  you refer to is. (sure, we can see the MOP-scale: DIO only, DAO-nonstoring, DAO-…

Leaf-only operation. Whether or not you'll float. 

> The implementation that we cite (URL is in the draft) is the ContikiRPL implementation, which only supports storing mode, and which consumes these ~50 KB (in the above link, they talk about 44KB be…

Right -- what fraction of the 44kB is RPL, and what fraction is the Contiki kernel? Saying 44kB is the size of RPL is similar to saying that xml2rfc is >2GB because Windows is >2GB. I realize that my analogy is far more extreme than the one above, but it seems that you're playing fast and loose with numbers in a way to support your argument and so again being disingenuous. That erodes my confidence in your claims.

> In addition, it is not just about efficient implementation from one vendor that could mitigate these problems, but rather about allowing for interoperable implementations in the same routing domain.

I don't think anyone expects an RFC to be perfectly precise. This is one reason why there are bake-offs. It could be that we take 4 RPL implementations, each of which has a slightly different DAO diffusion approach, and they all work together fine. Or they don't -- at which point we, as a working group, have found a specific issue through practice, and can write an RFC to better specify the solution.

> The point we want to make here is, that contrary to what we observe in simulations and modeling, when deploying trickle in wireless networks, one should expect more control traffic than seen in the…

If your point is that simulation and theoretical analysis of wireless networks are typically far from reality and therefore generally not very elucidating for real-world behavior, I'd agree with that. But I think there have been a bunch of experimental studies of how Trickle behaves in a dynamic and challenging network. The CTP paper, for example. One of things we found in CTP is that the routing topology is most dynamic when the network first starts up. Over time, if implemented carefully, nodes settle on stable rather than dynamic links and the control traffic continually decreases over the period of hours and even days. Fundamentally, nodes have to probe the RF environment to figure out which links are good and stable, and this takes time. There are some shortcuts (e.g., using physical layer information), but including something PHY-specific in an RFC is a big no-no.

> We are a little unclear on what you mean here, or what you suggest that we disagree on. Is it the use of "inconsistent" in the penultimate paragraph of  page 24? 

Yes.

Phil