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

[Junxiao Shi <[e-mail]>]

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

On Tue, Oct 1, 2019 at 6:44 AM Cenk Gündoğan <mail=2Bietf=
[e-mail]> wrote:

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