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

[Thomas Heide Clausen <[e-mail]>]

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
>