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

[Cenk Gündoğan <[e-mail]>]

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=
> [e-mail]> 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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg