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

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Mar 2013 14:22:04 +0100

On Aug 25, 2012, at 13:41, peter van der Stok <[email-masked]> 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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Mar 2013 22:25:06 +0100

On Mar 29, 2013, at 22:11, Mark Smith <[email-masked]> wrote:

> RFC5175, "IPv6 Router Advertisement Flags Option"

EFO was inspiration for 6CIO, but is different from 6CIO in that it is about flags promulgated by a router (and therefore can only be used in an RA).
6CIO is about the capabilities of the node sending that option.
That's why they are not the same thing.

6CIO is indeed meant to be general enough to carry other node capabilities that are relevant to a node-node situation.  ROHC-over-802 could have used it.  That's why I'm proposing creating an IANA registry. to make the other 47 bits available for other uses.

I'm completely neutral to whether GHC's compression scheme and 6CIO should be done in a combined draft or separate drafts.  In the latter case, stealing more text from 5175 is an obvious thing to do.

Is there anything that could/should be generalized about 6CIO?
(Without making it more complex, please.)

Grüße, Carsten