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

From: Thomas Björklund <[email-masked]>
Date: Thu, 06 Feb 2014 09:15:54 +0100

Hi all,

I have some questions and comments regarding draft-ietf-6lo-ghc-00,
which I have entered below.

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.

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?

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.

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.

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?

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?

/Thomas

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Feb 2014 11:13:46 +0100

(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.)

> string. I think this should be avoided.

OK, let me think about improving this editorially.

> with respect to size. What is sub optimal with the compressed output in

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.

> 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?

> 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.

> 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!

> could/should the way GHC capability is indicated be extended with a

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

---

From: Thomas Björklund <[email-masked]>
Date: Fri, 07 Feb 2014 08:23:20 +0100

Hi,

Thanks for your prompt reply!

2014-02-06 11:13, Carsten Bormann wrote:

>> 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.

It would be interesting to know, but it is not of great importance to me.

> 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 :-).
> 

Imho the use of a preloaded dictionary which is incrementally extended
with the plain text, backreferences into the dictionary to represent
strings, and the ability to represent strings without references into
the dictionary is a description of an method/algorithm for compression,
and this is also pretty much what LZSS is about.

> 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!

Unfortunately I have no IEEE 802.15.4/6LoWPAN traffic to share, but
couldn't one just use regular IPv6 traffic for generating the
dictionary? The reason why I focus so much on the initial dictionary and
how it was generated is that the frequency of 0x00 is quite high, both
in the static part of the dictionary and in the pseudo header,
especially if link-local addresses are used. Thanks to the existence of
the "append zeros" code byte my gut feeling is that that the initial
dictionary might be of better use with a different content.

/Thomas