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

[Philip Levis <[e-mail]>]

On Aug 30, 2011, at 2:10 AM, Thomas Heide Clausen wrote:

> All,
> 
> Let me reiterate what I said at the Quebec meeting at the microphone: I find it incomprehensible if - before the ink is dry on the RPL RFC and before an RFC number has even been assigned to the specification - the working group finds it necessary to invent a "compression mechanism" for RPL. 
> 
> After all, RPL was supposed to have been designed for networks with (among other characteristics) a small MTU.
> 
> If this document is necessary, then the logical conclusion would have to be that the initial design of (at least) the packet format of RPL was insufficient, and that therefore this document should either or both of "Updates/Obsoletes" RPL?
> 
> If this document is not intended to either or both of "Updates/Obsoletes" RPL, then I do not see any justification for the document being adopted.
> 
> Respectfully Yours,
> 
> Thomas

Thomas,

Apologies for the tardy response: I just returned from an (unheard of for Americans!) two week vacation with no email contact.

I fear that you might be misrepresenting the situation: RPL does not have an RFC number not because of uncertainty on its content, but rather for procedural reasons. Specifically, it references several other documents that are in the queue and its number can't be assigned until those dependencies are resolved.

That being said, you comment is totally valid: if compression is a big deal, why isn't it in the core spec? There was a lot of tension in writing the RPL document on completeness versus simplicity, with many people taking different positions. Some thought it should be split into three: the core spec, storing mode, and non-storing mode. Others thought up and down should be separate. Others still thought it should include more, such as the Trickle algorithm. After a lot of back-and-forth, I had though that we as a working group reached consensus that the one submitted to the IESG was a reasonable compromise between all of the different proposed approaches. That being said, I can assure you that if we'd added another X pages on compression, someone would have suggested we remove it and put it in a separate document.

Compression places a tradeoff between computational cost and code size/complexity versus packet size. Because it's a tradeoff, it seems like a mistake to mandate it; correspondingly, it's an optional approach, which practice, use and deployment will evaluate and validate or discard. So necessitating it in the core spec seems like a mistake to me. What do you think?

BTW, apologies I couldn't make Quebec, it would have been nice to catch up.

Phil