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

[Junxiao Shi <[e-mail]>]

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

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.


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

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