Subject: [Roll] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt

From: Mukul Goyal <[email-masked]>
Date: Wed, 18 May 2011 12:59:30 -0500 (CDT)

Hi all

Fragmentation of RPL control messages has emerged as one of the key concerns when RPL is run over IEEE 802.15.4 networks. The submitted draft specifies a compression mechanism for RPL control messages. We have currently specified compression formats for DIO messages and some of the options that sit inside a DIO. Future versions of this draft may include compression formats for other DIO options as well as other RPL control messages. The mechanism can even be extended to ICMPv6 messages in general.

Thanks
Mukul

----- Forwarded Message -----
From: [email-masked]
To: [email-masked]
Cc: "jerald p martocci" <[email-masked]>, "emmanuel baccelli" <[email-masked]>, [email-masked], "matthias philipp" <[email-masked]>, [email-masked]
Sent: Wednesday, May 18, 2011 12:50:20 PM
Subject: New Version Notification for	draft-goyal-6lowpan-rpl-compression-00.txt

A new version of I-D, draft-goyal-6lowpan-rpl-compression-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository.

Filename:	 draft-goyal-6lowpan-rpl-compression
Revision:	 00
Title:		 A Compression Format for RPL Control Messages Over a 6lowpan
Creation date:	 2011-05-17
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
   This document specifies a compression format for ICMPv6 RPL control
   messages over a 6lowpan.  The specified format is in accordance with
   IPv6 header compression framework defined for a 6lowpan.

The IETF Secretariat

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 18 May 2011 13:07:24 -0700

How does this compare to draft-bormann-6lowpan-ghc?  It seems most of the gain will be from compressing out prefixes and zeros, which ghc should handle quite well.

--
Jonathan Hui

On May 18, 2011, at 10:59 AM, Mukul Goyal wrote:

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

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 19 May 2011 10:28:56 -0500 (CDT)

I would be able to do a comparative analysis of two methods as soon as I understand the mechanism described in draft-bormann-6lowpan-ghc. I have already spent a couple of hours trying to understand draft-bormann. At the moment, I cant figure out how the compression mechanism (Section 2) works and how was it applied to the examples listed in the draft. I suspect the draft does not have sufficient level of explanatory text at the moment.

Thanks
Mukul

----- Original Message -----
From: "Jonathan Hui" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "6lowpan" <[email-masked]>, "roll" <[email-masked]>
Sent: Wednesday, May 18, 2011 3:07:24 PM
Subject: Re: [6lowpan] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt

--
Jonathan Hui

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 May 2011 18:06:11 +0200

> I would be able to do a comparative analysis of two methods as soon as I understand the mechanism described in draft-bormann-6lowpan-ghc. I have already spent a couple of hours trying to understand…

Hi Mukul,

as usual for compression specs, the spec defines the *de*compressor (on one page, because that's all that's needed -- ignore the experimental nibblecode part, as that doesn't seem to be too popular).
The spec does assume some basic familiarity with compression technology (it does not use anything that has not been known since the late 1970s, though), which you may want to look up.
As with most compression technologies, there are many ways to write a compressor, so specifying a compressor would be overspecification; of course, with the rather limited set of elements in the spec, there aren't *that* many ways of doing it.

When approaching such a specification, it is probably best to look at the examples and satisfy yourself that your understanding of the decompressor indeed generates the uncompressed bits.  The annotated example on slide 38 of the Prague 6LoWPAN tutorial slides (http://www.iab.org/about/workshops/smartobjects/tutorial/Bormann.pdf) might help, too. Then go ahead and think about a good way (reasonably efficient, but not complex) to generate the compressed bits.
The compressor I used for generating the examples is a bit simple-minded at about 50 lines of code (the decompressor is 30 lines).  It essentially runs through the uncompressed bytes, finding sequences of zeros and prefix matches in previous uncompressed bytes, and then (if both are the case) deciding somewhat naively which of the two are more compact; if none are the case, it generates a copy element up to the next useful match.

I you have pcaps of the kind of RPL messages that you want to compress with your spec, I could also simply run them through my example code.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 May 2011 18:26:54 +0200

Mukul,

I just looked at your draft in a little more detail.
Certainly, a purpose-built spec to squeeze out redundancy from a specific packet format will generally be more efficient than the generic compression I have written up.

However, the arguments in section 1.1 of draft-bormann-6lowpan-ghc-02.txt apply to the fullest here.
Since the HC spec needs to be understood by all nodes, it creates a powerful obstacle in evolving the subject protocol.  The strong coupling between the subject protocol and the compression spec also creates opportunity for interesting interoperability problems.

As a distant observer of the ROLL WG, one thing I don't understand is why this is necessary in the first place.
As far as I understand, the domain of RPL is low-power (i.e., constrained) networks.
6LoWPAN is just one of the network types RPL will be used on, and redoing this work for every other type (that benefits from compactness) sounds wasteful to me.
Why doesn't RPL itself define a reasonably compact representation then?

Gruesse, Carsten

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 19 May 2011 13:49:09 -0500 (CDT)

>6LoWPAN is just one of the network types RPL will be used on, and redoing this work for every other type (that benefits from >compactness) sounds wasteful to me.

I think that is a good idea. The reasons I targetted 6lowpan:

1) In my view, RPL over 6lowpan is a common case.
2) 6lowpan already has a mechanism for next header compression, that we could use.

Thanks
Mukul 

----- Original Message -----
From: "Carsten Bormann" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "6lowpan" <[email-masked]>, "roll" <[email-masked]>
Sent: Thursday, May 19, 2011 11:26:54 AM
Subject: Re: [Roll] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt

Mukul,

Gruesse, Carsten