Re: [6lo] [IANA #1200929] expert review for draft-irtf-icnrg-icnlowpan-10

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

Hello Pascal,

thanks for your helpful input.  I was able to squeeze out a bit for CCNx
messages by not encoding the version field and always relying on the
version number to be "1" (as mandated by RFC8609 [1]).  6LoWPAN follows
a similar philosophy [2].  I guess any serious protocol update may
require big changes on the compression scheme anyways.

If you are okay with the current allocations (diff: [3]), then I would
carry this change back to the icnrg mail list and initiate a version
update on positive feedback.

Cheers,
Cenk

[1] https://datatracker.ietf.org/doc/html/rfc8609#section-3.2
[2] https://datatracker.ietf.org/doc/html/rfc6282#section-3
[3] https://tools.ietf.org//rfcdiff?url1=draft-irtf-icnrg-icnlowpan-10&url2=https://inet.haw-hamburg.de/tmp/draft-irtf-icnrg-icnlowpan-11.txt/@@download/file/draft-irtf-icnrg-icnlowpan-11.txt

On Thu, Sep 23 2021 at 10:19 +0200, Cenk Gündoğan wrote:

> [[PGP Signed Part:Undecided]]
> Hello Pascal,
>
> the compressed NDN Interest + compressed NDN Data message dispatches
> have a few RSV bits.  Fixing the prefix on 4 bits might work for them.
> For the compressed CCNx Content Object message it already works since we
> removed the RSV bit in the proposed solution.
>
> Currently, the compressed CCNx Interest message dispatch consumes two
> full octets and has no RSV bits left.  That's the source of the
> asymmetry.  I'll have a look at that particular section to see if we can
> optimize something there and will report again.
>
> Thanks,
> Cenk
>
> On Thu, Sep 23 2021 at 07:31 +0000, Pascal Thubert (pthubert) wrote:
>
>> Hello Amanda;
>>
>> The current draft has this:
>>
>>     +-------------+------+-------------------------------------------+
>>     | Bit Pattern | Page | Header Type                               |
>>     +-------------+------+-------------------------------------------+
>>     |  00 000000  | TBD1 | Uncompressed NDN Interest messages        |
>>     |  00 100000  | TBD1 | Uncompressed NDN Data messages            |
>>     |  01 000000  | TBD1 | Uncompressed CCNx Interest messages       |
>>     |  01 100000  | TBD1 | Uncompressed CCNx Content Object messages |
>>     |  10 0xxxxx  | TBD1 | Compressed NDN Interest messages          |
>>     |  10 1xxxxx  | TBD1 | Compressed NDN Data messages              |
>>     |  11 0xxxxx  | TBD1 | Compressed CCNx Interest messages         |
>>     |  11 1xxxxx  | TBD1 | Compressed CCNx Content Object messages   |
>>     +-------------+------+-------------------------------------------+
>>
>> The Uncompressed form has the 4 rightmost bits set to 0 while the compressed has them xxxxx.
>> Which leaves lots of unassigned space un the Uncompressed range.
>>
>> This simple proposal seems to break the symmetry of compressed forms.
>>
>>
>>     |  10 0xxxxx  | TBD1 | Compressed NDN Interest messages          |
>>     |  10 1xxxxx  | TBD1 | Compressed NDN Data messages              |
>>     |  10 0xxxxx  | TBD1 | Compressed CCNx Interest messages         |
>>     |  11 10xxxx  | TBD1 | Compressed CCNx Content Object messages   |
>>
>> Maybe 4 bits is sufficient in all compressed forms? If so we can do better:
>>
>>     +-------------+------+-------------------------------------------+
>>     | Bit Pattern | Page | Header Type                               |
>>     +-------------+------+-------------------------------------------+
>>     |  00 000000  | TBD1 | Uncompressed NDN Interest messages        |
>>     |  00 000001  |      |                                           |
>>     |    ...      |      |      Unassigned                           |
>>     |  00 001111  |      |                                           |
>>     |  00 01xxxx  | TBD1 | Compressed NDN Interest messages          |
>>     |  00 100000  | TBD1 | Uncompressed NDN Data messages            |
>>     |  00 100001  |      |                                           |
>>     |    ...      |      |      Unassigned                           |
>>     |  00 101111  |      |                                           |
>>     |  00 11xxxx  | TBD1 | Compressed NDN Data messages              |
>>     |  01 000000  | TBD1 | Uncompressed CCNx Interest messages       |
>>     |  01 000001  |      |                                           |
>>     |    ...      |      |      Unassigned                           |
>>     |  01 001111  |      |                                           |
>>     |  01 01xxxx  | TBD1 | Compressed CCNx Interest messages         |
>>     |  01 100000  | TBD1 | Uncompressed CCNx Content Object messages |
>>     |  01 100001  |      |                                           |
>>     |    ...      |      |      Unassigned                           |
>>     |  01 101111  |      |                                           |
>>     |  01 11xxxx  | TBD1 | Compressed CCNx Content Object messages   |
>>     +-------------+------+-------------------------------------------+
>>
>> Works?
>>
>> Pascal
>>
>> This leaves unassigned space 
>>
>>> -----Original Message-----
>>> From: Amanda Baber via RT <[e-mail]>
>>> Sent: mercredi 22 septembre 2021 19:30
>>> Cc: Eric Vyncke (evyncke) <[e-mail]>; [e-mail];
>>> [e-mail]; [e-mail]; Pascal Thubert
>>> (pthubert) <[e-mail]>; [e-mail]; [e-mail]
>>> Subject: [IANA #1200929] expert review for draft-irtf-icnrg-icnlowpan-10
>>> 
>>> Hi,
>>> 
>>> IANA has been asked to notify the 6lo group and the authors of RFC 8025 as
>>> well as the IESG-designated experts that the authors of draft-irtf-icnrg-
>>> icnlowpan-10 (and the RG) have accepted a proposed change to an assignment
>>> in that document.
>>> 
>>> Carles and Shwetha, can you confirm that we can move forward with this
>>> registry update?
>>> 
>>> The issue is that Table 2 in https://datatracker.ietf.org/doc/html/draft-
>>> irtf-icnrg-icnlowpan is currently instructing IANA to make this
>>> registration in the Dispatch Type Field registry (we understand that this
>>> "TBD1" should be page 14):
>>> 
>>> 11 1xxxxx | TBD1 | Compressed CCNx Content Object messages
>>> 
>>> However, 11 11xxxx has already been assigned to "Page switch" for pages 0-
>>> 15:
>>> 
>>> https://www.iana.org/assignments/_6lowpan-parameters
>>> 
>>> This is the solution suggested by the experts and accepted by the authors:
>>> 
>>> =====
>>> 
>>> One simple solution could be as follows:
>>> 
>>> OLD:
>>> 11 1xxxxx | TBD1 | Compressed CCNx Content Object messages
>>> 
>>> NEW:
>>> 11 10xxxx | TBD1 | Compressed CCNx Content Object messages
>>> 
>>> A drawback of this solution is that it reduces the space of this type of
>>> messages (from 32 options to 16 options, for this specific type of
>>> messages), but perhaps it could be sufficient.
>>> 
>>> =====
>>> 
>>> The authors write, "The simple solution provided by the designated experts
>>> is sufficient. The drawback does not affect the option space, since that
>>> particular dispatch also contains a 'Reserved' bit. We can trade this for
>>> the longer prefix '11 10xxxx' (instead of '11 1xxxxx')."
>>> 
>>> Best regards,
>>> 
>>> Amanda Baber
>>> IANA Operations Manager
>>
>> _______________________________________________
>> 6lo mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lo