Re: [6lo] Questions and comments regarding draft-ietf-6lo-ghc-00.

[Carsten Bormann <[e-mail]>]

(I encouraged Thomas to send the below points to the mailing list.
I already had typed up responses to those, so I’m sorry if they don’t match the rephrased questions.)


> 1) In general I find the document easy to read and understand, however I
> think the description of the backreference code byte in Table 1 can be
> slightly improved. First, use the same order of the terms in the
> definition of n and s, e.g. n = na+0b00000nnn+2; s = sa+0b00000kkk+n.
> Further, n is used both as a variable name and to represent a bit
> string. I think this should be avoided.

OK, let me think about improving this editorially.


> 2) In the paragraph above Figure 9, one can read "Note that the
> compressed output exposes an inefficiency in the simple-minded
> compressor used to generate it". I find the compressed output optimal
> with respect to size. What is sub optimal with the compressed output in
> Figure 9?

I’m afraid I already forgot (I think it was about using one more “mode-switch” than needed).  But I can look at it again.



> 3) I think that it somewhere in the draft should be a reference to James
> Storer and Thomas Szymanski's description of LZSS in the article "Data
> compression via textual substitution", since the algorithm proposed for
> compression is very similar to theirs, so that the interested reader can
> learn more about the background.

I was very careful (too careful maybe) to avoid superfluous references to anything post LZ77.
Now LZSS is old enough that it should be patent-safe, so that is a good suggestion (a JACM reference never hurts, even if it doesn’t help very much :-).

Do I actually propose an algorithm for compression?


> 4a) Why was the entire pseudo header chosen to be a part of the initial
> dictionary? I guess that there might have been other candidates of what
> to put in the dictionary that didn't make it into the draft.

An IP implementation may already need to realize the pseudo-header for computing the UDP checksum, so it seemed obvious to stick to it.  There is also some specification economy.  It also didn’t seem morbidly big, given that you certainly want both the IP source and the IP destination address.  But it is certainly possible to substitute it by something better, if there is any such thing.


> 4b) What sort of packet trace was used to generate the static part of
> the dictionary? Is it possible to get a copy of it?

The traces we have are on http://svn.tools.ietf.org/svn/wg/6lowpan/packets
Not much, but it seems a bit hard to get real-world pcaps from people in this space.
If you have more that can be published this way, I’d sure like to put them up there!


> 4c) Is there any need for changing the content and size of the initial
> dictionary (pseudo header + static dictionary) in the future? If so
> could/should the way GHC capability is indicated be extended with a
> version number as well?

I thought about this a lot and decided against it.
I expect the protocol encodings (e.g., DTLS 1.3) to become better and be less in need of crutches of this kind.  
We already have the terrible split between non-GHC and GHC nodes.
But, as a life insurance, we do have enough bits in the 6CIO option to add a third cohort if that turns out to really be needed at some point.  (Version *numbers*, by the way, are almost never the right way to achieve protocol evolution.)


(We also discussed interop testing, and I pointed out that there will be an ETSI plugtest on Mar 7–9 where we can interop test GHC.  I also repeated my plea for packet traces that can be used to evaluate the compression.)

Grüße, Carsten