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

From: JP Vasseur <[email-masked]>
Date: Tue, 30 Aug 2011 10:18:47 +0200

Dear WG,

draft-goyal-roll-rpl-compression was discussed during the last ROLL WG meeting in Quebec, but
as usual we confirm on the mailing list. Are in favor of adopting this document as a WG document ?
Please reply on the mailing list.

Thanks.

JP.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 30 Aug 2011 11:10:01 +0200

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

On Aug 30, 2011, at 10:18 , JP Vasseur wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 30 Aug 2011 11:33:21 +0200

Hi Thomas,

I don't know about all the L2 technologies and all the applications that are
intended to be used in conjunction with RPL. It's not my concern, but I
suppose some of them may not need the compression scheme proposed in
draft-goyal-roll-rpl-compression? It's not for me to say.

All I know is that for the scenarios we target using P2P, we need a
compression scheme. draft-goyal-roll-rpl-compression thus proposes a
compression scheme tailored for this purpose.

If others also need a compression scheme for other purposes, let it be
known, and let's try to work on merging our requirements in the working
group document to be.

cheers,

Emmanuel

On Tue, Aug 30, 2011 at 11:10 AM, Thomas Heide Clausen <
[email-masked]> 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.
>
> 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
>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 30 Aug 2011 11:48:23 +0200

Hi Thomas,

Co-chair hat on,

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

Just chiming in since this is a procedural comment as opposed to technical, the WG will voice his opinion.

When a protocol is designed and the RFC has been approved, there is nothing that prevents WG to make
additions to it (isn't it what we are doing with pretty much all protocols ?). When you invent a new TLV for 
ISIS, you do not need to obsolete it ! Especially when the extension is NOT mandatory but optional … 
Just clarifying for the rest of the group.

Thanks.

JP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 30 Aug 2011 13:54:28 +0200

Hello

This was discussed many times in the ML and the point was always to make compression a separate spec to be implemented optionally for such types of LLNs that would require it.
It is good that the work has now started and I support it.

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JP Vasseur
Sent: mardi 30 août 2011 10:19
To: roll WG
Subject: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLLWG document

Dear WG,

draft-goyal-roll-rpl-compression was discussed during the last ROLL WG meeting in Quebec, but as usual we confirm on the mailing list. Are in favor of adopting this document as a WG document ?
Please reply on the mailing list.

Thanks.

JP.

---

From: "Popa, Daniel" <[email-masked]>
Date: Tue, 30 Aug 2011 05:06:41 -0700

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Baccelli
Sent: Tuesday, August 30, 2011 11:33 AM
To: roll WG
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Hi Thomas,

I don't know about all the L2 technologies and all the applications that are intended to be used in conjunction with RPL. It's not my concern, but I suppose some of them may not need the compression scheme proposed in draft-goyal-roll-rpl-compression? It's not for me to say.

All I know is that for the scenarios we target using P2P, we need a compression scheme. draft-goyal-roll-rpl-compression thus proposes a compression scheme tailored for this purpose.

If others also need a compression scheme for other purposes, let it be known, and let's try to work on merging our requirements in the working group document to be.

cheers,

Emmanuel

On Tue, Aug 30, 2011 at 11:10 AM, Thomas Heide Clausen <[email-masked]<mailto:[email-masked]>> wrote:
All,

Respectfully Yours,

Thomas

On Aug 30, 2011, at 10:18 , JP Vasseur wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 30 Aug 2011 11:12:21 -0500 (CDT)

Thomas

I am afraid I dont agree with your reasoning. Our draft specifies an optimization over the core spec. In many situations, you need this optimization and in many others you dont.

Regards
Mukul

----- Original Message -----
From: "Thomas Heide Clausen" <[email-masked]>
To: "JP Vasseur" <[email-masked]>
Cc: "roll WG" <[email-masked]>
Sent: Tuesday, August 30, 2011 4:10:01 AM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new	ROLL WG document

All,

Respectfully Yours,

Thomas

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Aug 2011 13:45:23 -0400

I am in favour of persuing work to accomodate compression, but the work
in goyal-roll-rpl-compression is not compression, it's a reduced scope,
non-extensible version of RPL.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 30 Aug 2011 13:24:58 -0500 (CDT)

I totally agree with Emmanuel. As I mentioned before, the compression mechanism is required in some application scenarios (e.g. in P2P routing where DIOs need to carry the Route Discovery Option additionally). The compression mechanism may not be required for many L2 technologies (with larger MAC payloads) or for many application scenarios (where DIOs do not carry many options).

Thanks
Mukul

----- Original Message -----
From: "Emmanuel Baccelli" <[email-masked]>
To: "roll WG" <[email-masked]>
Sent: Tuesday, August 30, 2011 4:33:21 AM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Hi Thomas, 

cheers, 

Emmanuel 

On Tue, Aug 30, 2011 at 11:10 AM, Thomas Heide Clausen < [email-masked] > wrote: 

All, 

Respectfully Yours, 

Thomas

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 30 Aug 2011 13:47:22 -0500 (CDT)

Michael

I was wondering if you have the compression scheme described in draft-bormann-6lowpan-ghc in mind. I guess it will be useful to compare the compression achieved using the two schemes for the two examples described in draft-goyal-roll-rpl-compression. I think that compression achieved with draft-bormann scheme would vary with the actual byte stream contained in the packet. There is ofcourse no such dependency in case of our scheme. 

Thanks
Mukul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Aug 2011 15:53:32 -0400

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> I was wondering if you have the compression scheme described
    Mukul> in draft-bormann-6lowpan-ghc in mind. I guess it will be
    Mukul> useful to compare the compression achieved using the two
    Mukul> schemes for the two examples described in
    Mukul> draft-goyal-roll-rpl-compression. I think that compression
    Mukul> achieved with draft-bormann scheme would vary with the actual
    Mukul> byte stream contained in the packet. There is ofcourse no
    Mukul> such dependency in case of our scheme.  

yes, but the goyal-roll-rpl-compression (GRRC from now on, okay?) scheme
will result in devices that support the compressed format only,
essentially creating an entirely new protocol. 

6lowpan-ghc applies things as a layered approach, which means that after
decompression, you still need a full RPL packet parser, which means that
the RPL protocol can in fact evolve.

goyal-roll-rpl-compression (GRRC) scheme will have to be revised each time
there is an addition to the protocol, and will cause a flag day, as no
node can use the new options until every node is upgraded, even if the
nodes do not need to make use of the new options.

In essence, the goyal-roll-rpl-compression is a fixed proprietary
system.

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 30 Aug 2011 12:58:21 -0700

I agree with Michael's concern that using GRRC could lead to
non-interoperable implementations, with some nodes "speaking" normal RPL,
some using GRRC. That might require some additional negotiation between
nodes, or worse, could lead to non-interoperable parts of the network. That
worries me.

Ulrich

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 30 Aug 2011 15:05:02 -0500 (CDT)

>essentially creating an entirely new protocol. 

This is not true. Compressed messages will have new code values. I quote the relevant text from the draft:

"Code: The Code value of the compressed version of an RPL ICMPv6
      message is obtained by setting the 7th bit in the Code value
      associated with the corresponding uncompressed message.  For
      example, the Code associated with a compressed DODAG Information
      Object is 0x40."

>the RPL protocol can in fact evolve.

I am not doubting that. I guess the important question to answer is whether the ghc scheme would provide enough compression. Or the devices with ghc would have to implement additional compression mechanisms (e.g. draft-goyal....) as well?

>there is an addition to the protocol,

Again not true. Any new additions to the protocol DO NOT require their compressed formats to be specified as well. One could ofcourse define compressed formats (or define only the compressed formats) if they are deemed useful. But it is not mandatory to do so.

> and will cause a flag day, as no

Simply not true.

>In essence, the goyal-roll-rpl-compression is a fixed proprietary system.

I am sorry but this is totally wrong characterization.

Thanks
Mukul

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 30 Aug 2011 15:06:43 -0500 (CDT)

By the same logic, you would argue that P2P-RPL would lead to non-interoperable implementations since some devices would speak P2P-RPL and others wont.

Thanks
Mukul

----- Original Message -----
From: "Ulrich Herberg" <[email-masked]>
To: "Michael Richardson" <[email-masked]>
Cc: "Mukul Goyal" <[email-masked]>, "roll WG" <[email-masked]>
Sent: Tuesday, August 30, 2011 2:58:21 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

I agree with Michael's concern that using GRRC could lead to non-interoperable implementations, with some nodes "speaking" normal RPL, some using GRRC. That might require some additional negotiation between nodes, or worse, could lead to non-interoperable parts of the network. That worries me. 

Ulrich 

On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson < [email-masked] > wrote: 

>>>>> "Mukul" == Mukul Goyal < [email-masked] > writes: 

  Kyoto Plus: watch the video < http://www.youtube.com/watch?v=kzx1ycLXQSE >

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 30 Aug 2011 15:09:55 -0500 (CDT)

Please realize that the compressed objects have different code values than regular objects. Hence there is no danger of lack of interoperability.

Thanks
Mukul

----- Original Message -----
From: "Mukul Goyal" <[email-masked]>
To: "Ulrich Herberg" <[email-masked]>
Cc: "roll WG" <[email-masked]>
Sent: Tuesday, August 30, 2011 3:06:43 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Thanks
Mukul

----- Original Message -----
From: "Ulrich Herberg" <[email-masked]>
To: "Michael Richardson" <[email-masked]>
Cc: "Mukul Goyal" <[email-masked]>, "roll WG" <[email-masked]>
Sent: Tuesday, August 30, 2011 2:58:21 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 30 Aug 2011 13:12:12 -0700

Yes, I indeed do argue the same way. Adding ever more companion documents to
RPL makes it more and more difficult to guarantee interoperable
implementations. But that's another topic.

Ulrich

On Tue, Aug 30, 2011 at 1:06 PM, Mukul Goyal <[email-masked]> wrote:

> By the same logic, you would argue that P2P-RPL would lead to
> non-interoperable implementations since some devices would speak P2P-RPL and
> others wont.
>
> Thanks
> Mukul
>
>   Kyoto Plus: watch the video < http://www.youtube.com/watch?v=kzx1ycLXQSE>
>                       then sign the petition.

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 30 Aug 2011 15:16:10 -0500 (CDT)

I am sorry but your argument is wrong.

Mukul 

----- Original Message -----
From: "Ulrich Herberg" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "roll WG" <[email-masked]>, "Michael Richardson" <[email-masked]>
Sent: Tuesday, August 30, 2011 3:12:12 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Yes, I indeed do argue the same way. Adding ever more companion documents to RPL makes it more and more difficult to guarantee interoperable implementations. But that's another topic. 

Ulrich 

On Tue, Aug 30, 2011 at 1:06 PM, Mukul Goyal < [email-masked] > wrote: 

Thanks 
Mukul 

----- Original Message ----- 
From: "Ulrich Herberg" < [email-masked] > 
To: "Michael Richardson" < [email-masked] > 
Cc: "Mukul Goyal" < [email-masked] >, "roll WG" < [email-masked] > 
Sent: Tuesday, August 30, 2011 2:58:21 PM 
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document 

Ulrich

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Aug 2011 16:19:55 -0400

>> the RPL protocol can in fact evolve.

    Mukul> I am not doubting that. I guess the important question to
    Mukul> answer is whether the ghc scheme would provide enough
    Mukul> compression. Or the devices with ghc would have to implement
    Mukul> additional compression mechanisms (e.g. draft-goyal....) as
    Mukul> well? 

So, I have not yet done the research to determine how much compression
we can get with ghc.

    >> there is an addition to the protocol,

    Mukul> Again not true. Any new additions to the protocol DO NOT
    Mukul> require their compressed formats to be specified as well. One
    Mukul> could ofcourse define compressed formats (or define only the
    Mukul> compressed formats) if they are deemed useful. But it is not
    Mukul> mandatory to do so. 

yes, but:
     1) will nodes know how to process the new extensions?
     2) will including the new extensions, uncompressed, blow the MTU,
     and so nobody will ever turn them on?

    >> nodes do not need to make use of the new options.

    Mukul> Simply not true.

    >> In essence, the goyal-roll-rpl-compression is a fixed proprietary system.

    Mukul> I am sorry but this is totally wrong characterization.

okay. I will re-read the document.  I admit that I read it quickly as
you presented in July, and your presentation worried me.

>   The
>   other RPL options, for which a compression format is not specified in
>   this document, MUST follow the format in which they are defined when
>   carried inside an RPL control message compressed as described in this
>   document.

1) So, how does a sending node know that all of recipients know about the
   compression of the current options?

2) How does a sending know that all of the recipients know about any new
   compressed option fields?

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 30 Aug 2011 13:20:21 -0700

Let me give an example: a node, "speaking" only uncompressed RPL messages,
joins the network. It needs to get the DODAG Configuration Option. Now the
other nodes (inclusive the root node) use the compressed RPL messages. How
can the new node get the required information then?

Similarly, what happens if that "classic" RPL node receives a compressed DIO
message? Yes, the message has a different code, and thus would not be parsed
by the node. Therefore, this node is excluded from network operation.

I would also like to repeat my question I raised during the ROLL meeting: If
we know now how to compress messages much better, why don't we update the
RPL specification, instead of adding new message / option types in
additional drafts?

Ulrich

On Tue, Aug 30, 2011 at 1:09 PM, Mukul Goyal <[email-masked]> wrote:

> Please realize that the compressed objects have different code values than
> regular objects. Hence there is no danger of lack of interoperability.
>
> Thanks
> Mukul
>

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 30 Aug 2011 13:21:23 -0700

That's a non-constructive statement, which does not help our discussion nor
for the progress of the WG.

Ulrich

On Tue, Aug 30, 2011 at 1:16 PM, Mukul Goyal <[email-masked]> wrote:

> Yes, I indeed do argue the same way. Adding ever more companion documents
> to RPL makes it more and more difficult to guarantee interoperable

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 30 Aug 2011 16:02:46 -0500 (CDT)

>     1) will nodes know how to process the new extensions?

I understand that you are arguing in favor of the ghc scheme. But the key question is whether we can depend on the ghc scheme alone to give us enough compression.

Not sure how such concerns constitute an argument against draft-goyal or in favor of your contention that every new extension would require their compressed formats to be defined. Compressed formats would be defined where they are deemed useful.

>   compression of the current options?

A compressed option has a different option type than its regular version. By looking at the option type, a node would know whether it is compressed or not.

>   compressed option fields?

The sending node does not know. The recipient would ignore the options it does not know about (or discard the whole message itself as specified in the core spec). 

I am not sure why the fact that nodes need to know about the compressed objects/options in order to process them is being used as an argument against this draft. RPL nodes would still be able to talk core RPL among themselves irrespective of whether they implement this draft or not. Their existing functionality is not affected. 

Thanks
Mukul

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 30 Aug 2011 17:18:19 -0500 (CDT)

Ulrich

1. Why would a node transmit only compressed DIOs when it expects its listeners to include those that do not understand compression? 

Your example seems similar to these:
a) A non-storing node not being able to join a storing mode DAG
b) A node that does not understand RPL security can't join a DAG using secure messages.

2. Assuming that the scenario you described is plausible, a simple DIS flag/option can be defined to solve the problem trivially. But ofcourse you would then complain about additional complexity.

Thanks
Mukul

----- Original Message -----
From: "Ulrich Herberg" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "roll WG" <[email-masked]>
Sent: Tuesday, August 30, 2011 3:20:21 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Let me give an example: a node, "speaking" only uncompressed RPL messages, joins the network. It needs to get the DODAG Configuration Option. Now the other nodes (inclusive the root node) use the compressed RPL messages. How can the new node get the required information then? 

Similarly, what happens if that "classic" RPL node receives a compressed DIO message? Yes, the message has a different code, and thus would not be parsed by the node. Therefore, this node is excluded from network operation. 

I would also like to repeat my question I raised during the ROLL meeting: If we know now how to compress messages much better, why don't we update the RPL specification, instead of adding new message / option types in additional drafts? 

Ulrich 

On Tue, Aug 30, 2011 at 1:09 PM, Mukul Goyal < [email-masked] > wrote: 

Thanks 
Mukul 

----- Original Message ----- 
From: "Mukul Goyal" < [email-masked] > 
To: "Ulrich Herberg" < [email-masked] > 
Cc: "roll WG" < [email-masked] > 
Sent: Tuesday, August 30, 2011 3:06:43 PM 
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document 

Thanks 
Mukul 

----- Original Message ----- 
From: "Ulrich Herberg" < [email-masked] > 
To: "Michael Richardson" < [email-masked] > 
Cc: "Mukul Goyal" < [email-masked] >, "roll WG" < [email-masked] > 
Sent: Tuesday, August 30, 2011 2:58:21 PM 
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document 

Ulrich 

Roll mailing list 
[email-masked]

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 30 Aug 2011 15:39:08 -0700

Mukul,

On Tue, Aug 30, 2011 at 3:18 PM, Mukul Goyal <[email-masked]> wrote:

> Ulrich
>
> 1. Why would a node transmit only compressed DIOs when it expects its
> listeners to include those that do not understand compression?
>

How would it know what its listeners expect? If there is a chance that any
of the nodes in the network does not understand compression (which none of
the other nodes would know), the nodes in the network either all use
uncompressed messages or deprive that node from communicating.

> 2. Assuming that the scenario you described is plausible, a simple DIS
> flag/option can be defined to solve the problem trivially. But ofcourse you
> would then complain about additional complexity.
>

Not only that I don't like that additional DIS flag for the reason you
mentioned (and which has to be specified somewhere), but I also think there
is a difference to the two examples you gave: If an implementation of RPL
does not support one Mode of Operation, this is a design choice; the
implementer knows that his/her implementation does not fully support the RPL
spec, so it is not expected to be fully interoperable. With the compression,
I can have a compliant (i.e. complete) RPL implementation, and it *still*
does not interoperate with all nodes (and I, as implementer, might not even
know about the compression format, since there is no reference to it in the
RPL spec).

Regards
Ulrich

> Similarly, what happens if that "classic" RPL node receives a compressed
> DIO message? Yes, the message has a different code, and thus would not be
> parsed by the node. Therefore, this node is excluded from network operation.
>
> I would also like to repeat my question I raised during the ROLL meeting:
> If we know now how to compress messages much better, why don't we update the

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Aug 2011 21:11:44 -0400

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> Not sure how such concerns constitute an argument against
    Mukul> draft-goyal or in favor of your contention that every new
    Mukul> extension would require their compressed formats to be
    Mukul> defined. Compressed formats would be defined where they are
    Mukul> deemed useful. 

And, then what?
Upgrade all the nodes in the building?  

    >> compression of the current options?

    Mukul> A compressed option has a different option type than its
    Mukul> regular version. By looking at the option type, a node would
    Mukul> know whether it is compressed or not. 

Great, so to be sure that everyone understands, I should send both? :-)

    Mukul> The sending node does not know. The recipient would ignore
    Mukul> the options it does not know about (or discard the whole
    Mukul> message itself as specified in the core spec).  

    Mukul> I am not sure why the fact that nodes need to know about the
    Mukul> compressed objects/options in order to process them is being
    Mukul> used as an argument against this draft. RPL nodes would still
    Mukul> be able to talk core RPL among themselves irrespective of
    Mukul> whether they implement this draft or not. Their existing
    Mukul> functionality is not affected.  

We are concerned about flag days and incremental deployment of new
features.  These features *INCLUDE* deploying new compressed options.

I agree with Ulrich: if we now know much better about what options are
essential and which ones are not, then let's just revise the spec, and
remove the uncompressed version.  I don't want to write and test the
code twice.

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 30 Aug 2011 21:07:55 -0500 (CDT)

>1. Why would a node transmit only compressed DIOs when it expects its listeners to include those that do not understand >compression? 

>How would it know what its listeners expect? If there is a chance that any of the nodes in the network does not understand >compression (which none of the other nodes would know), the nodes in the network either all use uncompressed messages or deprive >that node from communicating. 

The nodes would know because some body would configure that information in them. Suppose that LLN consists of some devices that understand compression and others that dont. Suppose a global DAG is required. In such situation, the simplest option would be to create two DAGs - one using compressed messages and the other using uncompressed ones. Another option would be to have some nodes transmit compressed DIOs and others transmitting uncompressed ones. Another option would be for a node to transmit uncompressed DIOs some times and compressed ones at other times. So, there are many ways to avoid the fate you are suggesting.  

>>2. Assuming that the scenario you described is plausible, a simple DIS flag/option can be defined to solve the problem >>trivially. But ofcourse you would then complain about additional complexity. 

>Not only that I don't like that additional DIS flag for the reason you mentioned (and which has to be specified somewhere),
> but I also think there is a difference to the two examples you gave: If an implementation of RPL does not support one Mode of >Operation, this is a design choice; the implementer knows that his/her implementation does not fully support the RPL spec, so it >is not expected to be fully interoperable. With the compression, I can have a compliant (i.e. complete) RPL implementation, and >it *still* does not interoperate with all nodes (and I, as implementer, might not even know about the compression format, since >there is no reference to it in the RPL spec). 

I dont quite understand. I no longer wish to use any negative adjective for your argument. I suppose you do not want to see any extension to RPL because any such extension would cause a "compliant/complete" implementation to be not interoperable with others (that include the extension). At the very least, you want to limit RPL extensions to those that have been explicitly mentioned/referenced in the core spec. 

Regards 
Mukul 

----- Original Message ----- 

To: "Mukul Goyal" < [email-masked] > 
Cc: "roll WG" < [email-masked] > 

Ulrich 

Thanks 
Mukul 

----- Original Message ----- 
From: "Mukul Goyal" < [email-masked] > 
To: "Ulrich Herberg" < [email-masked] > 
Cc: "roll WG" < [email-masked] > 
Sent: Tuesday, August 30, 2011 3:06:43 PM 
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document 

Thanks 
Mukul 

----- Original Message ----- 
From: "Ulrich Herberg" < [email-masked] > 
To: "Michael Richardson" < [email-masked] > 
Cc: "Mukul Goyal" < [email-masked] >, "roll WG" < [email-masked] > 
Sent: Tuesday, August 30, 2011 2:58:21 PM 
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document 

Ulrich 

Roll mailing list 
[email-masked]

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 30 Aug 2011 23:08:42 -0500 (CDT)

Michael

I understand your preference for GHC scheme. As for our scheme, it seems to me that you would like our scheme much better if there is a way for a node to solicit compressed/uncompressed DIOs. Is my understanding correct? This could be done by a simple DIS flag.

Thanks
Mukul

----- Original Message -----
From: "Michael Richardson" <[email-masked]>
To: "roll WG" <[email-masked]>
Sent: Tuesday, August 30, 2011 8:11:44 PM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new	ROLL WG document

And, then what?

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 31 Aug 2011 10:50:56 +0200

On Wed, Aug 31, 2011 at 04:07, Mukul Goyal <[email-masked]> wrote:
> The nodes would know because some body would configure that information in them. Suppose that LLN consists of some devices that understand compression and others that dont. Suppose a global DAG is required. In such situation, the simplest option would be to create two DAGs - one using compressed messages and the other using uncompressed ones.

What is compression useful for in that scenario?

Probably, at the end, you will save more energy using uncompressed RPL.

> Another option would be to have some nodes transmit compressed DIOs and others transmitting uncompressed ones.

In this case also, either the dissemination will be less efficient for
nodes understanding a single format, or you will transmit more packets
and for this reason there is no convenience in having the compression
at all.

> Another option would be for a node to transmit uncompressed DIOs some times and compressed ones at other times.

And you will be either less efficient, or introduce redundancy (why
compressing then?).

> So, there are many ways to avoid the fate you are suggesting.

Yes, but at the end of the day either you don't interoperate, or you
are less efficient, or you produce more traffic using compression
(!!).

Energy-efficiency is probably obtained only if the whole network is
compressing, and in this context I share the thought about pursuing it
as a requirement given the fact that RPL targets LLNs.

Best,
Angelo

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Aug 2011 09:35:49 -0400

>>>>> "Mukulu" == Mukul Goyal <[email-masked]> writes:
    >> 1. Why would a node transmit only compressed DIOs when it expects
    >> its listeners to include those that do not understand
    >> >compression?

    >> How would it know what its listeners expect? If there is a chance
    >> that any of the nodes in the network does not understand
    >> >compression (which none of the other nodes would know), the
    >> nodes in the network either all use uncompressed messages or
    >> deprive >that node from communicating.

    Mukulu> The nodes would know because some body would configure that
    Mukulu> information in them. Suppose that LLN consists of some

Manual configuration is being invoked too often in ROLL.
How does this deal with upgrades?

    Mukulu> devices that understand compression and others that
    Mukulu> dont. Suppose a global DAG is required. In such situation,
    Mukulu> the simplest option would be to create two DAGs - one using

Let's go back.
What's the purpose of compression?

It's so that one can transmit only a single frame, rather than two,
which halves the power consumption, and massively reduces impact of lost
frames.  (If ether frame of a fragment is lost, the entire packet is
lost).

So, creating two DAGs defeats all of this: you have to transmit a
minimum of three frames now.  One might as well have left out the
compressed DAG.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Aug 2011 09:38:32 -0400

>>>>> "Mukul" == Mukul Goyal <[email-masked]> 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.

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 31 Aug 2011 08:51:35 -0500 (CDT)

>I'd like the scheme not to fall apart when we

This is the part that I dont understand. Why does our scheme fall apart when a new option is introduced?

Mukul

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 31 Aug 2011 17:54:25 +0200

Dear Mukul,

> a) A non-storing node not being able to join a storing mode DAG

This was a thorny point during some discussions with the IESG. Personally, I do not agree with the outcome of those discussions, as documented in this specification, so I actually take the similarity to storing/non-storing mode as a red flag as to why this should be avoided.

We have "two RPL protocols" already, mutually non-interoperable:

	o	Storing mode RPL
	o	Non-storing mode RPL

Adding a different message format will give us "four RPL protocols", also mutually non-interoperable:

	o	Storing mode stock-RPL
	o	Non-storing mode stock-RPL
	o	Storing mode alternative-message-format-RPL
	o	Non-storing mode alternative-message-format-RPL

Add a P2P/non-P2P axis, and we're up to "eight RPL protocols", also mutually non-interoperable.

If all devices in a network come from the same vendor with the same firmware, and the network is never changed/reconfigured/extended, then it might work OK.

Then again, my big big worry here is the real world, in which a deployment will end up with heterogenous equipment from different vendors. This sounds like a royal configuration nightmare to get right.

Avoiding this should really be the _main_ design requirement that the WG should have been working towards.

Respectfully yours,

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 31 Aug 2011 17:54:29 +0200

> Please realize that the compressed objects have different code values than regular objects. Hence there is no danger of lack of interoperability.

Well, you effectively define an alternative protocol exchange format, and enforce  partitioning of the network in two: those supporting GRRC and those that do not. Or, MUST a router supporting GRRC also always support stock-RPL? Both in transmission and sending?

If I implement a thcRPL accepting/sending only stock-RPL messages, and Ulrich implements uhRPL using only the alternative GRRC-RPL message format, we can't interoperate. 

Must uhRPL support both stock-RPL and GRRC-RPL messages (i.e. have two parsers, …)? If so, how does uhRPL know of which format it should send messages? Or, must it always send both?

I do fear that this becomes either a deployment/configuration or signaling nightmare, especially in environments with heterogeneous suppliers of equipment (such as is the case in most of the networks that I am interested in).

Respectfully yours,

Thomas

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 31 Aug 2011 18:07:32 +0200

Hi Michael:

My take on this work is exactly the same as 6LoWPAN Header Compression. You will enable compression if all the devices support it. So you buy and deploy devices that support RFC blah and they interoperate. If someone comes in with a different compression - or different MAC frames for that matter, then that node cannot participate to that specific network. So in my mind there is no partial upgrade or mixed scenario. And if there was, GHC would not make a difference.

Also, I think that if we change RPL to RPLv2, I will not mind changing the compression to compression v2 at the same time, because probably the 2 RPL versions would not interoperate well. 

Anyway, I have no religion on the compression method. Probably the overall saving is a more important goal than implementation simplicity.  >From the GHC draft, it seems that we can expect from 1.2 to 1.9  ratio for RPL control packets. OTOH, 6LoWPAN HC+GHC could probably be applied to all data packets, and we could probably add some dictionary to overcompress 6LowPAN and the RPL headers. If there's a lot more data than control, that certainly counts. 

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: mercredi 31 août 2011 15:39
To: Mukul Goyal
Cc: roll WG
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a newROLL WG document

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.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 31 Aug 2011 17:54:58 +0200

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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 31 Aug 2011 17:55:00 +0200

I would actually argue that RPL and P2P-RPL are two entirely different protocols (albeit sharing some commonalities in the overall message structure).

There are ways of making multiple routing protocols co-exist on the same routers (and in the same network). However I am not sure that it is such  a good idea to do so in a LLN.

I've always found it odd that P2P traffic was not supported in RPL -- and really, dog-leg routing through a DODAG root and using source routing isn't (efficiently) supporting P2P.

In short, I do agree with Ulrich's logic.

Respectfully yours,

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 31 Aug 2011 17:54:55 +0200

>      example, the Code associated with a compressed DODAG Information

So, Michael is right in his observation that it is not a "compressed" format, but an "alternative" format.

Question: what expressiveness is lost by using the "alternative" GRRC format over the verbose stock RPL format? What would be lost, in terms of  functionality, by replacing the stock RPL format by GRRC? What additional parsing/encoding complexity does GRRC incur over RPL (if any, it may also be less complex)?

>> nodes do not need to make use of the new options.

I always find it preferable to try to educate those I disagree with, rather than declaring their opinions as "simply not true". So, while I do agree with Michael's ultimate opinion on the alternate RPL message format proposed, let me try to do Mukul's job here and educate a bit ;)

Quoting from section 4 of the draft:

  This section defines the compression format for some of the RPL
   options that may be carried inside an RPL control message.  These RPL
   options SHOULD be compressed when carried inside an RPL control
   message compressed in the manner described in this document.  The
   other RPL options, for which a compression format is not specified in
   this document, MUST follow the format in which they are defined when
   carried inside an RPL control message compressed as described in this
   document.

In other words, the draft proposes the ability to carry uncompressed options inside a compressed message.

Note that I'm not expressing an opinion on if that is or is not a valid design choice.

Respectfully yours,

Thomas

---

From: JP Vasseur <[email-masked]>
Date: Wed, 31 Aug 2011 18:39:42 +0200

Dear Thomas,

On Aug 31, 2011, at 5:54 PM, Thomas Heide Clausen wrote:

> However then the working group should fix the problem in RPL by updating that specification,

Once again, there is no fix to have. 

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

---

From: JP Vasseur <[email-masked]>
Date: Wed, 31 Aug 2011 18:41:04 +0200

> I've always found it odd that P2P traffic was not supported in RPL -- and really, dog-leg routing through a DODAG root and using source routing isn't (efficiently) supporting P2P.

Thomas, 

I cannot let you say this … you perfectly know that the core specification of RPL supports P2P traffic.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 31 Aug 2011 18:57:10 +0200

> I cannot let you say this … you perfectly know that the core specification of RPL supports P2P traffic.

Ah, but you must, JP, you must. 

Note that I said in the above that RPL supports P2P traffic by way of dog-leg routing through the DODAG root, then source routing -- that's the _only_ way P2P is supported, guaranteed to work across all the different RPL-flavors (storing/non-storing with/without RPL-P2P, …) that the WG is exploring.

I suppose that if the incurred route-stretch, increased over-the-wire overhead and number of transmissions (across a lossy medium, increasing loss probability) are of no concern, then this is sufficient support……? 

Respectfully yours,

Thomas

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Aug 2011 13:06:32 -0400

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> introduce another option type.

    Mukul> This is the part that I dont understand. Why does our scheme
    Mukul> fall apart when a new option is introduced?

Because, when the new option is introduced:
  1) I need to know if a node supports it in regular or compressed
     format, assuming that a compressed format is defined also defined.
     This means that we had better define a compressed format with
     every new option!  But, why do that at all?  Just make sure that
     it is already efficiently encoded.
        
  2) if the presence of the new option blows the MTU, then there is
     significant pressure to never include that option, ever.

  3) if these compressed formats work so well, then let's throw out
     rpl-19, and use the old formats, and the code involved.

Problem #2 is particularly important, and has caused delays for new
things.  The new thing is not implemented as efficiently, and as a
result, even turning it on slows down the other parts.

For instance on a number of router platforms, for instance, IPv6
forwarding was not in ASIC, but in the slow path.  This meant that even
a small (1-2%) mix of IPv6 traffic would degrade ipv4 service.  While we
haven't even reached that level today, just the risk of degradation
caused IPv6 to stay disabled.

I started looking at doing some kind of straight huffman-type encoding,
perhaps using a static (pre-distributed) tree.  I'm not an expert here.
This kind of thing could possibly be put into hardware, and would apply
to all future extensions.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 31 Aug 2011 19:05:18 +0200

> Note that I said in the above that RPL supports P2P traffic by way of dog-leg routing through the DODAG root, then source routing -- that's the _only_ way P2P is supported, guaranteed to work acros…
Well the sentence was, to say the least, strangely worded … As you know, you go via the root only if you deploy non-storing.

So I guess that we agree

Kind Regards.

JP.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 31 Aug 2011 19:08:50 +0200

> Well the sentence was, to say the least, strangely worded … As you know, you go via the root only if you deploy non-storing.

Well, given the state requirements for storing-mode in networks larger than a few handful of routers, non-storing mode seems to be the only realistic choice for the lions share of deployments that I am aware of. 

Thus, dog-leg-source-routing is pretty much the only viable option - and you must admit that it's not a particularly elegant or efficient option at that?

Thomas

---

From: JP Vasseur <[email-masked]>
Date: Wed, 31 Aug 2011 19:10:46 +0200

> Thus, dog-leg-source-routing is pretty much the only viable option - and you must admit that it's not a particularly elegant or efficient option at that?

*if* you think that this not elegant enough (which has to be demonstrated IMO), then you must be supportive
of the P2P IDs work that the WG has been working on ?

Thanks.

JP.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 31 Aug 2011 19:25:12 +0200

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

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 31 Aug 2011 19:50:00 +0200

Le 31/08/2011 19:10, JP Vasseur a écrit :
>>>> >> I would actually argue that RPL and P2P-RPL are two entirely
>>>> different protocols (albeit sharing some commonalities in the
>>>> overall message structure).
>>>> >>
>>>> >> There are ways of making multiple routing protocols co-exist on
>>>> the same routers (and in the same network). However I am not sure
>>>> that it is such a good idea to do so in a LLN.
>>>> >>
>>>> >> I've always found it odd that P2P traffic was not supported in
>>>> RPL -- and really, dog-leg routing through a DODAG root and using
>>>> source routing isn't (efficiently) supporting P2P.
>>>> >
>>>> > Thomas,
>>>> >
>>>> > I cannot let you say this … you perfectly know that the core
>>>> specification of RPL supports P2P traffic.
>>>>
>>>> Note that I said in the above that RPL supports P2P traffic by way
>>>> of dog-leg routing through the DODAG root, then source routing --
>>>> that's the _only_ way P2P is supported, guaranteed to work across
>>>> all the different RPL-flavors (storing/non-storing with/without
>>>> RPL-P2P, …) that the WG is exploring.
>>>>
>>> Well the sentence was, to say the least, strangely worded … As you
>>> know, you go via the root only if you deploy non-storing.
>>>
>>
>> Well, given the state requirements for storing-mode in networks larger
>> than a few handful of routers, non-storing mode seems to be the only
>> realistic choice for the lions share of deployments that I am aware of.
>>
>> Thus, dog-leg-source-routing is pretty much the only viable option -
>> and you must admit that it's not a particularly elegant or efficient
>> option at that?
>
> *if* you think that this not elegant enough (which has to be
> demonstrated IMO), then you must be supportive

it's not a matter of elegance but of the routing being shortest path 
different than routing being trees and dags in a computer's memory.

mip has dogleg routing and mechanisms to alleviate it (ro) imposed by 
the sheer size of Internet (not the case of rpl nets), no need of new 
mechanisms to avoid dogleg in small nets - there exist simple mechanisms 
already to do that.

imho,

Alex

>
> Thanks.
>
> JP.
>
>>
>> Thomas
>>
>>> So I guess that we agree
>>>
>>> Kind Regards.
>>>
>>> JP.
>>>>
>>>>
>>>> I suppose that if the incurred route-stretch, increased
>>>> over-the-wire overhead and number of transmissions (across a lossy
>>>> medium, increasing loss probability) are of no concern, then this is
>>>> sufficient support……?
>>>>
>>>> Respectfully yours,
>>>>
>>>> Thomas
>>>>
>>>>
>>>> >>
>>>> non-interoperable implementations since some devices would speak
>>>> P2P-RPL and others wont.
>>>> >>>
>>>> >>> Thanks
>>>> >>> Mukul
>>>> >>>
>>>> >>> From: "Ulrich Herberg" <[email-masked]
>>>> <mailto:[email-masked]>>
>>>> >>> To: "Michael Richardson" <[email-masked]
>>>> <mailto:[email-masked]>>
>>>> >>> Cc: "Mukul Goyal" <[email-masked] <mailto:[email-masked]>>, "roll
>>>> WG" <[email-masked] <mailto:[email-masked]>>
>>>> non-interoperable implementations, with some nodes "speaking" normal
>>>> RPL, some using GRRC. That might require some additional negotiation
>>>> between nodes, or worse, could lead to non-interoperable parts of
>>>> the network. That worries me.
>>>> >>>
>>>> >>> Ulrich
>>>> >>>
>>>> >>>
>>>> >>> On Tue, Aug 30, 2011 at 12:53 PM, Michael Richardson <
>>>> [email-masked] <mailto:[email-masked]> > wrote:
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>>>>>> "Mukul" == Mukul Goyal < [email-masked]
>>>> <mailto:[email-masked]> > writes:
>>>> >>> ] [email-masked] <mailto:[email-masked]>
>>>> http://www.sandelman.ottawa.on.ca/ |device driver[
>>>> >>> Kyoto Plus: watch the video <
>>>> http://www.youtube.com/watch?v=kzx1ycLXQSE >
>>>> >>> then sign the petition.
>>>> >>> [email-masked] <mailto:[email-masked]>
>>>> >>> [email-masked] <mailto:[email-masked]>
>>>> >> [email-masked] <mailto:[email-masked]>

---

From: Jiazi YI <[email-masked]>
Date: Wed, 31 Aug 2011 23:28:50 +0200

Dear all,

> Mukul is proposing an optional compression mechanism, currently discussed by the WG, that's it.
Considering this "optional mechanism", I think some of us might concern:

1. The interoperability with the "main mechanism".  It's hard for me to
agree the statement that "there is no danger of lack of
interoperability" for a protocol -- especially for a "optional
mechanism" with its main document, developed in almost the same period. 
Even for a router with this compression mechanism, it might facing the
problem of sending out message in which format.

2. If the interoperability is hard to achieve, it's better to make it
clear how to make the choices:
        - in which kind of scenarios, this should be applied, and what's
the benefit of it regarding reducing fragmentation and overhead.
        - what is the cost of using this option (performance,
complexity, etc?)

If the cost of compression is acceptable and considering the scale of
network and heterogeneous environment, it seems to me that, for this
"optional mechanism", it's actually always necessary.
      If it doesn't do any harm to the performance, it might make more
sense to update RPL itself ... Considering the complexity, if I was a
engineer who needs to implement RPL, I won't mind reading 4 more pages,
after taking care of the 160-page RPL draft (RFC), to save the trouble
of interoperability and fragmentation.

respectfully yours,
Jiazi 

-- 
Jiazi YI

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Aug 2011 17:46:23 -0400

>>>>> "Thomas" == Thomas Heide Clausen <[email-masked]> writes:
    Thomas> I'd much like a routing protocol, designed for low-power,
    Thomas> lossy networks and with low-MTU MACs as one of its
    Thomas> design-target to be able to run over these networks. If
    Thomas> _this_ early a need for an alternative, more compact, packet
    Thomas> format is identified, then by all means let's get RPL
    Thomas> updated to use that alternative, more compact, packet
    Thomas> format. I have absolutely no problems with that.

+1