Subject: [icnrg] Comments on draft-irtf-icnrg-icnlowpan-04

From: "Mosko, Marc <[email-masked]>" <[email-masked]>
Date: Wed, 24 Jul 2019 18:51:49 +0000

Here is some feedback on the static compression sections.

* Because this uses an implied ordering of fields, one can only use it on packets where (1) the fields occur in the implied order or (2) not (1 and there is a (MAC or a Signature)).  That is, out of order fields are OK if not MAC'd or signed.  If MIC'd, you would need to recompute the MIC when decompressing.

* It would be good in this section to mention that the compressed LEN uses a different encoding.  From Fig 3 it looks like it is the same field. 

I made some comments about the original compression scheme we proposed at IETF 95.  I talked about the dictionary approach, but forgot to mention that we have a dictionary-based static compression.  This uses a standard dictionary that all nodes would implement, based on expected token frequency.  Here is a quick summary of that static approach.

In our original TLV compression scheme [1], we used both a static dictionary and learned dictionary.  Both approaches encode the T & L into different bit widths in 1, 2, or 3 octets.  These can be either fixed-length fields or variable length fields.  There would need to be different dictionaries for CCNx and NDN, as the occurrence of tokens are different.

I think it would worth coming up with some test vectors from actual packets and seeing how the proposed static compression compares to [1].  The advantage of [1] is that it encodes both T and L and it can compress strings of T & L, such as when there are 2 or 3 or 4 consecutive containers like in signature sections.  It also does not have any implied field ordering.  This means it works for all packets, even those that do not conform to an expected structure.  In particular, it works for typed name components.

If we can come up with a set of test vectors for NDN & CCNx, I would be happy to run those through the compressor in [1] to provide those data points.

[1] https://datatracker.ietf.org/meeting/interim-2016-icnrg-02/materials/slides-interim-2016-icnrg-2-7, in particular slides 21, 31, 32.

Marc