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

[Philip Levis <[e-mail]>]

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