Subject: [6lo] GHC: Comments regarding the initial dictionary.

From: Thomas Björklund <[email-masked]>
Date: Wed, 26 Mar 2014 09:44:06 +0100

Hi all,

In draft-ietf-6lo-ghc-00 it is stated that the initial dictionary shall
contain the pseudo header of the "current packet" and a 16 byte long
fixed string. The format of the pseudo header is described in RFC 2460
and contains the field Upper-Layer Packet Length.

1) During compression it is quite easy to create the initial dictionary,
since the Upper-Layer Packet Length is known, or can be computed without
too much effort. However, during decompression the Upper-Layer Packet
Length is not always known, since it might have been elided from the
headers as a part of the header compression described in RFC 6282.

An example of when this happens is when UDP is carried over IPv6 with at
least one extension header. In this case the lengths of the GHC
compressed extension header and UDP header/payload are not known before
decompression, hence Upper-Layer Packet Length can't be computed.

One could of course perform the decompression in two sweeps, one to
figure out the length of the GHC compressed parts to be able to compute
the correct Upper-Layer Packet Length, and one to do the actual
decompression, however my gut feeling is that the additional complexity
is greater than the benefits of having it there.

In my opinion the Upper-Layer Packet Length shall not be a part of the
initial dictionary.

2) If the Upper-Layer Packet Length is replaced with zeros the initial
dictionary will contain long strings of only zeros. Out of the 56 bytes
in the initial dictionary there will be four strings containing 1, 2, 5
and 7 sequential zeros, and that is excluding the sequences of zeros
that we will probably see in the part of the dictionary generated from
IPv6 addresses. Since sequences of zeros can be efficiently compressed
using the 1000nnnn code byte my gut feeling is that a carefully chosen
initial dictionary with fewer zeros could result in higher compression
efficiency.

Unfortunately I don't have access to any IPv6 traffic that could be
considered representative for 6lowpan networks. If I had, I would be
happy to help out with constructing such a dictionary.

3) As mentioned above the dictionary shall contain the pseudo header of
the "current packet". If one considers an IPv6 over IPv6 scenario the
term "current packet" is a bit ambiguous in my opinion. In RFC 6282 the
term "encapsulating header" is used to refer to the innermost header
containing address information, which I guess is what is meant by
"current packet". Perhaps the same term could be used here as well.

/Thomas, Effnet AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 26 Mar 2014 10:56:20 +0100

Hi Thomas,

I support your concerns. I read the draft quickly before weeks and I
felt there are things missing. I agree that the word packet is not
clear within the 6Lo environment. The draft scope is not clear either
for me especially after reading authors reply discussion in Feb 2014
(but still some may think there is only editorials changes). I needed
answers from authors or any who adopted the draft, but still waiting
reply.

Best Regards

AB

On 3/26/14, Thomas Björklund <[email-masked]> wrote:
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>