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

[Thomas Björklund <[e-mail]>]

Hi,

Thanks for your prompt reply!

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

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

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

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

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.

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

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