[6lowpan] GHC now crunches DTLS (Re: [Roll] draft-bormann-ghc)

[Carsten Bormann <[e-mail]>]

On Aug 25, 2012, at 13:41, peter van der Stok <[e-mail]> wrote:

> GHC applied to DTLS encrypted messages is interesting indeed. It may represent an important number of messages to transmit.
> I would concentrate on getting the GHC on DTLS results known and then start pushing ghc draft.

It took a while, but is now done:  GHC-06 is ready for consumption.

Htmlized:        
http://tools.ietf.org/html/draft-bormann-6lowpan-ghc-06
Diff:            
http://www.ietf.org/rfcdiff?url2=draft-bormann-6lowpan-ghc-06

It turns out my gut feeling about how to design this was just about right, so with all the research done, the only technical change from the previous version is the addition of a 16-byte static dictionary.  This should result in about a 3-line change in an implementation (and 16 bytes of increased temporary buffer size).  The specification no longer fits on a single page because that includes a note about the reserved code points.

I also have removed the speculative parts of GHC-05 -- there was little interest in the added complexity.  There is a little bit of innovative formatting because I'm using XML2RFCv2 now; there should be fixes for this soon.

The examples have been expanded to show the compression of DTLS handshake and application data messages; if you subtract the actual payload (cleartext and authenticator), the total DTLS overhead is around 8 bytes for application data (so, including the TLS_PSK_WITH_AES_128_CCM_8 authenticator, a DTLS message is 16 bytes longer than an uncompressed NoSec one). The examples section also shows the very slight overall improvement to the compression (including a regression, where the example ND advertisement now needs a byte more).

I'm pretty sure now that we have reached the point of diminishing returns.
If we still had an active WG, I'd go for WG adoption and a WGLC soon.
We'll see how to handle this in the shutdown phase of the 6lowpan WG.
In the meantime, please do send in your comments (preferably to the 6LoWPAN list).

I'm CCing 6man because part of the proposal is a new ND (ICMPv6) option for node capability indication.
Specific comments on that probably best go to the 6man mailing list.

Grüße, Carsten