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

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 1 Sep 2011 10:03:30 +0200

+1

On Wed, Aug 31, 2011 at 23:46, Michael Richardson <[email-masked]> wrote:
>
>>>>>> "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
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 1 Sep 2011 10:26:01 +0200

On Wed, Aug 31, 2011 at 18:07, Pascal Thubert (pthubert)
<[email-masked]> wrote:
> 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.

I think that by introducing compression we are already working to a
completely different version of RPL, in which the packet format is
updated.

Moreover I think that the term compression leads to some confusion, it
is not a general compression but a more synthetic packet format of
some "critical" packets and options.

Given that supporting both a verbose and a synthetic packet format for
interoperability, is a pain and adds even more overhead, why shouldn't
we want to require the use of the synthetic packet format.

Probably a good solution to this problem will be defining over which
kind of L2 mediums the use of the synthetic packet formats.

EXAMPLE: If the DIO message does not fit in a single frame MUST be
using the "synthetic packet format" (MUST be "compressed").

Best,
Angelo

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 1 Sep 2011 10:32:03 +0200

I slightly changed my mind about this +1.

Probably a good way to avoid this problem is to require the update of
the RPL packet format only for those mediums where the use of a
synthetic packet formats is a strong requirement (e.g. 802.15.4).

As detailed in , the conditions can be characterized in a more general
way, avoiding referencing single technologies in the standard:
"If the L2 medium does not support frames longer than X, than only the
synthetic packet format MUST be used."

In this way we avoid manual configuration and supporting both formats
in devices that target implementing this spec on very limited L2
medium.

In other words, synthetic packet format should be a MUST for some
lower layer technologies characterized by some parameters (without
referencing specific technologies).

Best,
Angelo

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Sep 2011 09:44:54 -0400

>>>>> "Angelo" == Angelo P Castellani <[email-masked]> writes:
    Angelo> Probably a good way to avoid this problem is to require the
    Angelo> update of the RPL packet format only for those mediums where
    Angelo> the use of a synthetic packet formats is a strong
    Angelo> requirement (e.g. 802.15.4).

No. You still massively increase the testing effort for no gain.

-- 
]       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: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 1 Sep 2011 15:53:48 +0200

> No. You still massively increase the testing effort for no gain.

As long as I can implement only the smaller format in
energy-constrained networks and be interoperable, my gain is clear.

Probably I would have preferred a more compact RPL message format
everywhere, however now this seems to be not possible anymore.

There was some messages in this thread saying that it was decided on
the ML that RPL should not have only the synthetic packet format, so
for this reason the best option for low-power (short-frames,
low-bandwidth) networks is to have the synthetic format as a MUST on
them.

Angelo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 1 Sep 2011 16:22:54 +0200

Hello Angelo

For the current features, RPL is now complete. We could have done
smaller options but that's not the way the WG decided to go. 
The idea was and is still that for a constrained environment, an
additional compression could take place as an adaptation layer, not as a
protocol replacement.
This is what 6LoWPAN HC does for 802.15.4 based networks for instance.
That approach is being extended for multiple other LLC/MACs, including
Bluetooth and DECT. 

And GHC http://tools.ietf.org/html/draft-bormann-6lowpan-ghc-02 extends
the approach for RPL and other protocols.

For me the question is really whether GHC is the final answer or if we
should recommend something more specific to RPL, for instance adding a
little bit of dictionary into it.

If GHC appears to be the right approach, then let it be known and let us
find a WG to host it. If we prefer a more RPL-specific compression, then
maybe we can host it.

In any fashion, I'd think that the compression needs to improve not only
the control, but also the data packets.

Cheers,

Pascal
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Angelo P. Castellani
Sent: jeudi 1 septembre 2011 15:54
To: Michael Richardson
Cc: roll WG
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a
new ROLL WG document

> No. You still massively increase the testing effort for no gain.

As long as I can implement only the smaller format in energy-constrained
networks and be interoperable, my gain is clear.

There was some messages in this thread saying that it was decided on the
ML that RPL should not have only the synthetic packet format, so for
this reason the best option for low-power (short-frames,
low-bandwidth) networks is to have the synthetic format as a MUST on
them.

Angelo

---

From: Jiazi YI <[email-masked]>
Date: Thu, 01 Sep 2011 16:28:26 +0200

> low-bandwidth) networks is to have the synthetic format as a MUST on
if I understand well, this is what "ROLL" stands for.

> everywhere
if it doesn't do any harm to the performance, and MUST be used for "low
power, low-bandwidth" networks... +1

-- 
Jiazi YI

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 1 Sep 2011 16:59:59 +0200

Thanks Pascal for the interesting response.

Some comments (and more questions) inline.

> smaller options but that's not the way the WG decided to go.

OK, I understand that the WG did not decided to go for a "compact"
format (everywhere).

Some questions about the design of the current message format:
1) What are the benefits of having a protocol targeting LLNs with very
big flexible base message format?
2) Wouldn't a more parsimonious packet format, more defaults, more
in-line fields be a better tradeoff?

> That approach is being extended for multiple other LLC/MACs, including

I am not against compression work and I personally like that efforts,
such as 6LoWPAN.

However we should remember that 6LoWPAN is born as the "IPv6 over IEEE
802.15.4" whereas IPv6 targets the whole Internet and obviously
requires an adaptation layer to adapt to the various lower-layer
technologies.

The work that 6LoWPAN WG has done is very useful, and much work will
be shared (hopefully in a single document) even for different lower
layers.

However, in my understanding of ROLL, this WG is born targeting LLNs,
where short-frames and low-bandwidth is the norm rather than the
exception.

> the control, but also the data packets.

In my understanding, GHC is a general purpose compression method, that
should be applied to address the fact that we can't expect that every
protocol will be redesigned or compressed to go on power-constrained
networks.

Native power-constrained protocols probably can natively get better
results by considering the fact that are being designed for such
networks.

Best,
Angelo

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Sep 2011 11:37:41 -0400

>>>>> "Angelo" == Angelo P Castellani <[email-masked]> writes:
    Angelo> On Thu, Sep 1, 2011 at 15:44, Michael Richardson
    >> No. You still massively increase the testing effort for no gain.

    Angelo> As long as I can implement only the smaller format in
    Angelo> energy-constrained networks and be interoperable, my gain is
    Angelo> clear.

Agreed.  And you are making my point: once you have smaller format,
there is no reason why any energy constrained device would ever have the
original format.

Which is why, if this is useful, then we should have one format only.
It doesn't hurt non-energy constrained, non-MTU-constrained devices to
use fewer bytes.

    Angelo> There was some messages in this thread saying that it was
    Angelo> decided on the ML that RPL should not have only the
    Angelo> synthetic packet format, so for this reason the best option
    Angelo> for low-power (short-frames, low-bandwidth) networks is to
    Angelo> have the synthetic format as a MUST on them.

I don't know that the ML concluded that.
I thought that most people felt that we should have one format.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 1 Sep 2011 17:44:01 +0200

We have been quite  a bit more parsimonious than classical IPv6.
Examples: the length is expressed in bytes, the RH has a prefix
factorization...
Still, we have refrained to optimize for one specific type of LLN; as
you know, LP 802.11 and recent variations of 802.15.4 support IPv6 min
MTU.
And we have kept reserved fields. They are set to 0 and easy to
compress, and at the same time the protocol is open to future
extensions.

Many sorts of them actually. In one extreme there can be a really
optimized adaption layer for each type of LLN and for each given
protocol in which case it probably makes sense to leave the work to the
IPv6-over-foo WG. GHC is the other end of that spectrum, where we can
get a reasonable benefit independent of the MAC and for all sorts of
packets.

Yes, that's the discussion I had hoped we'd have with this thread, and
the reason why I support this work. You'll note that GHC reuses the
6LoWPAN context and can probably compress efficiently the costly target
and transit options, as well as the routing header.

My own take is that it is a good start for us, and that we should study
its applicability and then figure if/where more specific macros
can/need-to be applied. 

Cheers,

Pascal

---

From: C Chauvenet <[email-masked]>
Date: Fri, 2 Sep 2011 03:22:07 -0700

Hi, 

Because RPL is a Route-Over routing protocol, it is applicable to many different L1/L2, including the well-known 802.14.5 and their last improvements/updates, PLC  and many others ...

Thus, I think we should avoid to bind RPL to some specifics L1/L2, or we would need to update RPL for each new L1/L2 created that aim to use RPL.

Cédric.

---

From: C Chauvenet <[email-masked]>
Date: Fri, 2 Sep 2011 04:48:22 -0700

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 <[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: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 2 Sep 2011 16:08:49 +0200

> compress, and at the same time the protocol is open to future

Do you believe that avoiding having defaults, bit-flagged header
parsing and in-line fields is useful for some implementations?

It's not that complex to be handled and typically is handled
successfully in very constrained devices (see 6lowpan
implementations).

I still don't get why:

a) having lots 0s in some implementations and the optional requirement
for a separate generic compression layer.
b) or in some implementation with strict power constraints, the
requirement for a separate (!!) RPL adaptation layer

could simplify, in general, RPL systems.

> [...]

I want to clarify better my point: I am NOT advocating to have an
optimization for a specific LL.

I will prefer having in RPL something like the following text:

<<If the lower link layer has the following characteristics:

MAX_FRAME_SIZE < K

then you MUST use the shorter format X for DIO, Y for DAO, Z for Option N>>

In this way we are not bounded to a specific link layer

> the reason why I support this work.

I support this work too, as long as we are not introducing the added
complexity of handling both formats for interoperability.

I would prefer that given a link layer technology having some
high-level characteristics, only one message format is permitted.

> You'll note that GHC reuses the

Definitely, reusing context information (if possible) is a very good approach.

> its applicability and then figure if/where more specific macros

Sure, let's discuss about this.

Best,
Angelo

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 2 Sep 2011 16:31:56 +0200

Hi,

> Thus, I think we should avoid to bind RPL to some specifics L1/L2, or we would need to update RPL for each new L1/L2 created that aim to use RPL.

Sure!

As clarified in the previous message, I am NOT telling to bind RPL to
a specific LL.

I believe that given a specific LL, message format to be used on it
should be a MUST and not an implementation decision.

The format to be used on a specific link layer should be identified
using some high-level characteristics of the link-layer itself (i.e.
MAX_FRAME_SIZE): in this way we will not bind to any specific LL.

The main advantage of this is that no confusion will exist about which
message format to use on any link-layer, and any implementation will
interoperate with each without requiring that nodes (at least some)
support both formats.

Best,
Angelo

---

From: Ietf Roll <[email-masked]>
Date: Fri, 2 Sep 2011 23:38:20 -0700 (PDT)

Cedric wrote:

[rav] Yes and RPL certainly needs improvements. :-)  And compressing out a bunch of unused bits would be a good improvement.

[rav] Yes you are correct that nodes can interoperate if they all adhere to the same RFC (or in RPLs case - lots of RFCs already - and more if you want to do P2P and more if you want to to do non-storing mode, but I digress).
         We are talking about a change to the core specification that will cause interoperability problems from the outset.  If I rely on the uncompressed spec RFC (oh wait, it isn't an RFC yet) I can't speak to you if you rely on this new compression
         scheme.  If we decide to go forward this this, then we have to have some way to negotiate between nodes to say if you are or are not using compression (oops another I-D). OR everyone has to implement both which goes against the notion
         that we are designing constrained nodes.

         If this compression is a good idea, then let's make it part of the core spec, get rid of the extra wasted bits and try to make RPL useful on constrained nodes.  This draft, if it is adopted by the WG, should deprecate the RPL core spec and fix it.

rav

---

From: Ietf Roll <[email-masked]>
Date: Fri, 2 Sep 2011 23:42:09 -0700 (PDT)

No one is talking about (or should not be talking about binding rpl to any specific l1/l2, but we are talking about compressing bits and that is useful on ANY l1/l2 - 802.15.4, 802.15.4g, 802.11LP and PLC.  Less bits sent means less time on air, less contention, less power, less less less.  So let's attempt to fix RPL now and get rid of the packet bloat.

rav

________________________________
From: C Chauvenet <[email-masked]>
To: Angelo P. Castellani <[email-masked]>
Cc: roll WG <[email-masked]>
Sent: Friday, September 2, 2011 4:22 AM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Hi, 

Cédric.

---

From: C Chauvenet <[email-masked]>
Date: Sat, 3 Sep 2011 07:40:05 -0700

Hi,

yes I agree, that was the introduction of my mail about my feeling on the compression.

Happy that we agree on that.

Cédric.

Le 3 sept. 2011 à 08:42, Ietf Roll a écrit :

rav

________________________________
From: C Chauvenet <[email-masked]<mailto:[email-masked]>>
To: Angelo P. Castellani <[email-masked]<mailto:[email-masked]>>
Cc: roll WG <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 2, 2011 4:22 AM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Hi,

Cédric.

Le 1 sept. 2011 à 10:32, Angelo P. Castellani a écrit :

> <[email-masked]<mailto:[email-masked]>> wrote:
>> +1
>>
>> On Wed, Aug 31, 2011 at 23:46, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>>>>>> "Thomas" == Thomas Heide Clausen <[email-masked]<mailto:[email-masked]>> writes:
>>> [email-masked]<mailto:[email-masked]>
> [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: Sat, 3 Sep 2011 09:47:30 -0500 (CDT)

I would like to respectfully submit that I find it very hard to accept the argument that a protocol should not be extended because the devices that dont implement the extension can't talk to devices that do. The compression scheme we proposed seems like a good optimization to us for some of the applications we are concerned with. Whether this is absolutely the best approach for all possible RPL applications, I dont know. As Pascal suggested, it is important to compress both data and control messages. May be GHC is a better approach. We will find out.

There was a lot of opposition to adding more stuff to core RPL. The (valid) argument was that any further additions would be introduced as supplementary documents. Now that core RPL is (almost) done, objections in the name of interoperability are being raised to deny useful extensions of the protocol and even to attack the core protocol itself. I find it to be a sorry state of affairs.

Thanks
Mukul   

----- Original Message -----
From: "Ietf Roll" <[email-masked]>
To: "C Chauvenet" <[email-masked]>, "Thomas Heide Clausen" <[email-masked]>
Cc: "roll WG" <[email-masked]>
Sent: Saturday, September 3, 2011 1:38:20 AM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new	ROLL WG document

Cedric wrote: 

rav

---

From: C Chauvenet <[email-masked]>
Date: Sat, 3 Sep 2011 07:50:18 -0700

Hi,

The last part of my mail you didn't mentioned in your reply talked about the 6loWPAN work which has done some previous work on compression.
I think the 6LoWPAN WG and people involved into it have answers to the point you are exposing.
I'm feeling that doing some compression in RPL is not so far from doing compression like 6LoWPAN.
Your point seems to be related to the general compression mechanism, not especially RPL.

What do you think ?

ps : What about saying "hi" and "regards" in mails, and assume your opinion through a real name and affiliation ?

respectfully,

Cédric.

Le 3 sept. 2011 à 08:38, Ietf Roll a écrit :

Cedric wrote:

rav

---

From: Michael Richardson <[email-masked]>
Date: Sat, 03 Sep 2011 22:36:15 -0400

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> There was a lot of opposition to adding more stuff to core
    Mukul> RPL. The (valid) argument was that any further additions
    Mukul> would be introduced as supplementary documents. Now that core
    Mukul> RPL is (almost) done, objections in the name of
    Mukul> interoperability are being raised to deny useful extensions
    Mukul> of the protocol and even to attack the core protocol
    Mukul> itself. I find it to be a sorry state of affairs.

The issue Mukul is that GRRC is not an addition to RPL, it is a
replacement.

(I don't know who "[email-masked]" is, it would be nice if you could
use a real name, or at least use a useful pseudonym)

---

From: Mukul Goyal <[email-masked]>
Date: Sun, 4 Sep 2011 18:35:49 -0500 (CDT)

Michael

It is not a replacement. It is an optional feature. This feature is to be used in deployments that consider it to be useful. Such deployments would probably have all devices implement this feature. Or such deployments would be OK with the fact that any devices that do not implement this feature would not be able to talk to the devices that do. Other deployments need not use this feature. 

Thanks
Mukul

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 5 Sep 2011 15:45:52 +0200

On Mon, Sep 5, 2011 at 01:35, Mukul Goyal <[email-masked]> wrote:
> Such deployments would probably have all devices implement this feature. Or such deployments would be OK with the fact that any devices that do not implement this feature would not be able to talk to the devices that do. Other deployments need not use this feature.

The same thing happens when there are 2 protocol competing for
providing a similar feature.

Usually leading to a period of time, before a de facto standard will
emerge, where either:

a) different implementation using different protocols don't interoperate
b) both protocols have to be implemented for interopeability

The point that some people is arguing is:

- do we really need two different RPL dialects to exist?
- if yes, do we want this even if this could lead to a similar
situation of when two completely different protocols exist offering a
similar feature?

Best,
Angelo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Sep 2011 16:01:24 +0200

Hello Angelo

> - do we really need two different RPL dialects to exist?

I, for one, do not. I think that once decompression has occurred, we
should get RPL packets as defined in the spec. 

If more than one compression method exist over a same MAC in a same
network, or if nodes use compression and others do not, then we are in a
situation that is equivalent to different MACs over the same band, or
different cryptos. DIOs have to be sent twice, etc.

So people will have to be careful as to when and how they deploy new
stuff. It is probably preferable to limit the number of gateways that
have to repeat their multicast DIOs over multiple networks. But that's a
deployment issue.

Cheers,

Pascal

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 5 Sep 2011 16:07:11 +0200

> have to repeat their multicast DIOs over multiple networks. But that's a

Why shouldn't we avoid this complexity defining, using a set of
guidelines (e.g. if MAX_FRAME_SIZE<X use compressed-format-N), which
format MUST be used on any L2?

A.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Sep 2011 22:17:34 -0400

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> It is not a replacement. It is an optional feature. This
    Mukul> feature is to be used in deployments that consider it to be

It's not optional.
It's required for deployments that need it.  You just said that.

It is sufficiently useful a thing that I, and many others, want to
simply make it required, if we are going to use it at all.

Anyone who wants to sell product into places that might need is going to
have to implement it.  As such, I can see no reason to implement the
synthetic version.  Rip that code out, stop testing it, be done with it.

Assuming that is, that we aren't painting ourselves into a corner.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Sep 2011 16:43:15 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> I, for one, do not. I think that once decompression has
    Pascal> occurred, we should get RPL packets as defined in the spec.

    Pascal> If more than one compression method exist over a same MAC in
    Pascal> a same network, or if nodes use compression and others do
    Pascal> not, then we are in a situation that is equivalent to
    Pascal> different MACs over the same band, or different
    Pascal> cryptos. DIOs have to be sent twice, etc.

This is a signaling problem as well as an interop problem.

GRRC assumes 6LowPAN HC, and if one assumes that, then one has solved
the signaling problem.  

I'm not yet convinced that GRRC can be made completely transparent to
the security parts of RPL, such that a packet can be "decompressed",
passed to another link-layer which does not have HC (such as ethernet), 
and still retain all it's expressiveness.