I submitted a version of draft-bormann-6lowpan-ghc that is fully implementable
(i.e., it defines how to do GHC capability detection).
I also added an experimental extension of the compression called "nibblecode"
-- I haven't made up my mind whether that is a good idea or too much complexity
for too little gain (compression factor 1.30 in one example).
Again, enjoy at:
http://tools.ietf.org/html/draft-bormann-6lowpan-ghc
The two new sections clearly stand out at:
http://tools.ietf.org/rfcdiff?url2=draft-bormann-6lowpan-ghc-02.txt
Any attempt at optimization is stupid without measurements. About half of the
non-boilerplate pages of the draft show how GHC compresses real packets. ***
I'm still looking for more packet captures from real 6LoWPANs ***. If you have
anything with DHCP, DNS, or even TCP/HTTP on it, I'd like to hear from you!
See you all in Prague!
Gruesse, Carsten
On Oct 23, 2010, at 23:49, Carsten Bormann wrote:
> Before IETF78, we had a discussion about the size of certain packets such as
> the 6lowpan-ND Router Advertisements. At the time, I pointed to a pre-draft
> that contained a basic design for a header compression scheme addressing this
> and other oversized packets in the 6lowpan operational protocols.
>
> On Jul 12, 2010, at 17:48, I wrote:
>
>> The actual spec in there is a single page (but doesn't define how it is
>> integrated with hc-07 NHC yet; that will be another paragraph and might use
>> up the reserved code). It will probably need another page of "Here's a nice
>> way to use it" for general ICMP, ND, DHCP and RPL, each.
>
> That spec is now complete (and still a single page for the compression, plus
> another page for how it works together with the finished 6lowpan-HC).
> (Actually, the spec already is a -01, simplified from -00 *and* getting
> slightly better compression.)
>
> There are also six pages of examples showing the compression of actual
> packets from the 6lowpan packets repository; the compression factors are not
> as good as they could be with a specially-made compression scheme for each
> format, but they seem surprisingly good for a 1-page spec.
>
> Enjoy at:
> http://tools.ietf.org/html/draft-bormann-6lowpan-ghc
>
> Before/in Beijing, we maybe can discuss whether we want to have something
> like this in 6lowpan, and, if yes, which parts of the design we want to use.
>
> (Then I'll fix the Security Considerations section and add the missing text
> about fragment boundaries.)
>
> Gruesse, Carsten
>
> PS.: If someone can provide a pcap file for one of the RPL formats not yet
> shown in the Examples section, I would be grateful. Of course, any other
> real-world captures, including DHCPv6, also would help.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
