Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-icnlowpan-05.txt

From: Cenk Gündoğan <[email-masked]>
Date: Tue, 01 Oct 2019 12:44:32 +0200

Hello Junxiao,

thank you for the great feedback. The proposed name compression on the
interim slides is an alternative to the "default name compression" in
the current version of the draft. While the "default name compression"
in the document only compresses names purely consisting of
"GenericNameComponentTypes", the "alternative" approach encodes a
minimum number of name component types and lengths into 1 octet (as you
also correctly described in your mail below). The result is a name
compression scheme that supports names of a) longer lengths than 15
octets and 2) consisting of different name component types. It is,
however, inferior to the "default compression" in the document
w.r.t. encoded octets (for names <= 15 octets && all
components=Generic).

We (as a group) *still* need to make a decision on which poison to
pick. What is your preference on this topic?

In addition to the discussion above, the ICNLoWPAN document now contains
an extensibility mechanism that enables external drafts to update the
(name) compression schemes. Thus, we can add more elaborate schemes
depending on CCNx/NDN protocol changes later on.

Below are further comments.

On Sun, Sep 29 2019 at 14:08 +0200, Junxiao Shi wrote:

> Hi Cenk
>
> I saw the interim meeting slides and the idea about allowing typed name
> components: two bits to encode one of four frequently used name component
> types, and six bits to encode TLV-LENGTH up to 63.
> The types selected are: Generic, Timestamp, Version, SequenceNum. I wonder
> what's the basis of this selection? Segment type has been used extensively
> in many NDN protocols, including file transfer, NFD Management, and NLSR.
> However, I can't say the same for IoT apps, despite my own building sensing
> app has been using Segment type always set to zero "for consistency with
> other NDN protocols".
>

So, I presume that you suggest a different selection? Which component
would you replace for "Segment"? (if we want to stick with 2 bits).

> One possibility is leaving this choice to the deployment. Parameters are:
> (1) how many bits for TLV-TYPE and how many bits for TLV-LENGTH (2) the
> TLV-TYPE table.
> Either a network administrator needs to configure these parameters, or the
> device could report its preference at startup time, to be associated with
> ContextID as described in Section 8.1.
> Once the parameters are configured or established through ContextID
> mechanism, the compression format of Name is determined according to the
> parameters.
> The default state without parameters could be Generic only, because it's
> unfair to pick a specific set of types and discriminate against apps trying
> to use others.

I like your proposal of 1) having the number of bits for each category
configurable and 2) of leaving the component selection to the network
administrator. Though, I really think that the vanilla behaviour
(without any configurations) should encode more than just the
GenericType. That's why I chose 4 types (2 bits) in the first
place. I also think that 6 bits (0--63 octets) are enough to encode
component lengths in IoT scenarios, am I wrong?

>
>
> P.S. typo in Section 8.2, (1...128) should be (1...127)
>

Sounds sensible. Thanks for the hint.

Best,
Cenk

> Yours, Junxiao
>
> On Thu, Sep 19, 2019, 13:32 Cenk Gündoğan <mail=2Bietf=
> [email-masked]> wrote:
>
>> Dear ICNRG,
>>
>> this update adds an extensibility mechanism to the ICNLoWPAN dispatch
>> format. This allows future I-Ds to extend the compression rule set
>> and to react to changes in the CCNx and NDN packet format.
>>
>> Further, I want to bring our last discussion on the name compression
>> topic into focus (former mail is attached). The very essence of this
>> discussion is:
>>
>> * the current default name compression strategy in ICNLoWPAN is
>>   restrictive, but effective, if ((only generic-typed name components
>>   are used) && (all component lengths <= 15 octets)). Also note that
>>   this stateless compression is invoked hop-wise and mostly for
>>   Interests only, since returning name prefixes for Data messages are
>>   elided by the stateful compression and added by ICNLoWPAN before
>>   passing the Data packet to the CCNx/NDN network stack.
>>
>> * do we want to keep the simple name compression (above) as default
>>   and work on more elaborate compression schemes (including
>>   static/dynamic dictionary-based approaches, e.g.) as part of future
>>   I-Ds? The new extensibility mechanism (in the last update) surely
>>   opens the door to future I-Ds that solely focus on the name
>>   compression and which simply integrate into ICNLoWPAN.
>>
>> We will bring up this discussion again during the interim meeting in
>> Macau and a lively discussion on site or on the list is greatly
>> appreciated (:
>>
>> Cheers,
>> Cenk
>>
>>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Junxiao Shi <[email-masked]>
Date: Wed, 2 Oct 2019 10:43:38 -0400

Hi Cenk

Whatever you choose as four default component types, someone will be
unhappy because their application is using a different type.
Thus, it's better not to make any selections.

   - NameCompressionStrategy=00: allow only GenericNameComponent.
   - NameCompressionStrategy=11: allow all name component types.

Specific selections can be made through ContextID mechanism. I hope you'll
get to it soon.

In allowing all name component types, one question is whether to compress
TLV-TYPE numbers using section 5.1 format, or send Name TLV-VALUE
uncompressed.
A comparison between uncompressed TLV-TYPE and section 5.1 format, for all
possible name component types:

TLV-TYPE range  | uncompressed size | section 5.1 size
----------------|-------------------|-----------------
0x01   ~ 0xFC   | 1                 | 1
0x00FD ~ 0x00FE | 3                 | 1
0x00FF ~ 0x01FD | 3                 | 2
0x01FE ~ 0x02FC | 3                 | 3
0x02FD ~ 0x03FB | 3                 | 4
0x03FC ~ 0x04FA | 3                 | 5
0x04FB ~ 0xFFFE | 3                 | 6 ~ 257
0xFFFF          | 3                 | 258

If we use section 5.1 compression format, it is:

   - same for range 0x01~0xFC and 0x01FE~0x02FC
   - shorter for range 0x00FD~0x01FD
   - longer for range 0x02FD~0xFFFF

All current assignments are in 0x01~0xFC range, so both choices are the
same. However, any future assignment >=0x02FD would put the compressed
format at a disadvantage. Thus, I'd suggest sending Name TLV-VALUE
uncompressed.

After writing the above table, I have to ask: is section 5.1 format really
useful for TLV-TYPE?
TLV-TYPE is a flat number space. Larger number such as 0xFFF0 is as likely
to appear as smaller number such as 0x0100, but the "compression" result
varies greatly.
Maybe the base 128 varints format from Protocol Buffers
<https://developers.google.com/protocol-buffers/docs/encoding#varints> is a
better choice?

TLV-TYPE range          | uncompressed size | base128 size
------------------------|-------------------|-------------
0x01       ~ 0x7F       | 1                 | 1
0x80       ~ 0xFC       | 1                 | 2
0x00FD     ~ 0x3FFF     | 3                 | 2
0x4000     ~ 0xFFFF     | 3                 | 3
0x00010000 ~ 0x001FFFFF | 5                 | 4
0x00200000 ~ 0x0FFFFFFF | 5                 | 5
0x10000000 ~ 0xFFFFFFFF | 5                 | 6

Comparing to uncompressed, base128 is:

   - same for range 0x01~0x7F and 0x4000~0xFFF and 0x00200000~0x0FFFFFFF
   - shorter for range 0x00FD~0x3FFF and 0x00010000~001FFFFF
   - longer for range 0x80~0xFC and 0x10000000~0xFFFFFFFF, but these ranges
   are for application use
   <https://named-data.net/doc/NDN-packet-spec/0.3/types.html#tlv-type-number-reservations>
in
   the Content payload and application could choose a different compression
   format

For TLV-LENGTH, section 5.1 format makes a lot of sense. I can see that the
current document uses section 5.1 format for TLV-LENGTH only, and don't
find anywhere it's used for TLV-TYPE. Maybe change the title "TLV Encoding"
to "TLV-LENGTH encoding"?

P.S. typo in section 5.3.3 "Name Copmression Strategy" => "Name Compression
Strategy"

Yours, Junxiao