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

[C Chauvenet <[e-mail]>]

Hi all, 

First, I think that we all agree that every bit saved in LLNs is a good thing.

That's why I definitely support the effort in defining a compression mechanism for RPL.

I was quite amazed by the storm messages created by this good initiative, but it seems that some messages were not fully related to the discussion Object.
It is sad because it may have discourage people to dig into this interesting discussion.

That's said, I don't see any problem for trying to design some improvements for RPL.
I think this rule is the same for every protocols.

As already mentioned in this discussion, it's all about *optional* improvements.
Designing new mechanism like compression doesn't mean that you HAVE to implement them.
So I don't  see why nodes won't interoperate if they all rely on the same RPL RFC.

Note that having a RFC speeds up implementations, as the protocols gets stable, and indeed push interoperability forward.
So I think that RPL becoming a RFC is a good thing, without preventing improvements, nor further modifications.

A lot of good work as been done in the 6loWPAN WG about compression, and I think we may find a good amount of good materials looking back to their work.
I think that some of the concerns raised in this discussion may found some answers in 6loWPAN HC early discussions.

Best,
Cédric.

Le 31 août 2011 à 19:25, Thomas Heide Clausen a écrit :

> 
> On Aug 31, 2011, at 18:39 , JP Vasseur wrote:
> 
>> Dear Thomas,
>> 
>> On Aug 31, 2011, at 5:54 PM, Thomas Heide Clausen wrote:
>> 
>>> I think that this is somewhat going to the crux of what I was referring to when I suggested updates/obsoletes RPL in case this (or, any) compression scheme is introduced.
>>> 
>>> As I understood the original design scope of ROLL, as retained in the charter, 802.15.4 was one of the (but, not the only) target L2's. It may be that a less verbose message format is required for 802.15.4 than that currently proposed in RPL - in fact, we've got some indications from our testing that this is the case (even for stock RPL) to avoid fragmentation.
>>> 
>>> However then the working group should fix the problem in RPL by updating that specification,
>> 
>> Once again, there is no fix to have. 
> 
> I would submit that if when running RPL on 802.15.4 I manage to get fragmented RPL control packets, then there's something that should be fixed in a protocol from a working group, which has 802.15.4 among its design targets.
> 
> Daniel Popa said in his email that:
> 
>> Hi Emmanuel, Thomas,
>> 
>> One case where we do not necessarily need compression is the use of the new IEEE 802.15.4 amendments, specifically designed for smart grids. 802.15.4g is a PHY Layer for Smart Utility Networks and 802.15.4e, a new MAC sub-layer that among others functionalities provide support for a 4g PHY layer.  For information, 4g PHY amendment mandates the support of IPv6 MTU.  
>> 
>> Regards,
>> Daniel
> 
> It seems that Daniel indicates that there may be exceptional MACs where compression isn't needed. But, it also seems that in the majority of the cases, it is needed and thus should be default.
> 
> Do note that my main point is, that "simple is good". 
> 
> As Michael has said repeatedly, having two different, incompatible, packet formats is extra overhead in coding and testing and isn't without complications for extensibility etc. 
> 
> As Ulrich and Michael have pointed out, there are issues when running two different and incompatible flavors of RPL (as would be the case if there were two different packet format) in the same network. If such is prohibited, then the WG has effectively created 4 different, non-interoperable protocols as previously enumerated.
> 
> I'd much like a routing protocol, designed for low-power, lossy networks and with low-MTU MACs as one of its design-target to be able to run over these networks. If _this_ early a need for an alternative, more compact, packet format is identified, then by all means let's get RPL updated to use that alternative, more compact, packet format. I have absolutely no problems with that.
> 
> I do, however, think that it should be avoided adding yet another component of functionality and complexity to an already complex protocol. And, it should be avoided to adding another set of non-interoperable modes-of-operation rendering deployments more complex.
> 
> Respectfully yours,
> 
> Thomas
> 
>> Mukul is proposing an optional compression mechanism, currently discussed by the WG, that's it.
> 
>> Thanks.
>> 
>> JP.
>> 
>>> rather than propose an alternative, incompatible message format as an option which - as Michael has pointed out in this and previous messages - necessitating writing/testing multiple different parsers, additional signaling to ensure that in a given deployment messages are sent in the "right" format (or, do we disallow heterogenous deployments?) etc.
>>> 
>>> I'm concerned that the WG, so early after (well, before) that RPL is published as RFC feels the need to consider such "patches" to the protocol.
>>> 
>>> Respectfully yours, 
>>> 
>>> Thomas
>>> 
>>> On Aug 31, 2011, at 15:38 , Michael Richardson wrote:
>>> 
>>>> 
>>>>>>>>> "Mukul" == Mukul Goyal <[e-mail]> writes:
>>>> Mukul> I understand your preference for GHC scheme. As for our
>>>> Mukul> scheme, it seems to me that you would like our scheme much
>>>> Mukul> better if there is a way for a node to solicit
>>>> Mukul> compressed/uncompressed DIOs. Is my understanding correct? 
>>>> Mukul> This could be done by a simple DIS flag.
>>>> 
>>>> No, I wouldn't like that.   I'd like not to have to write and test two
>>>> parsers for options, and I'd like the scheme not to fall apart when we
>>>> introduce another option type.
>>>> 
>>>> I will evaluate GHC method, and write a draft this long weekend with my
>>>> results.   If anyone has sample RPL messages they want me to consider, 
>>>> I would appreciate a PCAP file, otherwise, I'll evaluate only my own.
>>>> In particular, I need more examples of metric options.
>>>> 
>>>> 
>>>> -- 
>>>> ]       He who is tired of Weird Al is tired of life!           |  firewalls  [
>>>> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
>>>> ] [e-mail] http://www.sandelman.ottawa.on.ca/ |device driver[
>>>> Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
>>>> 	               then sign the petition. 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> Roll mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/roll
>> 
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>