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 <[email protected]> >>> Sent: mercredi 22 septembre 2021 19:30 >>> Cc: Eric Vyncke (evyncke) <[email protected]>; [email protected]; >>> [email protected]; [email protected]; Pascal Thubert >>> (pthubert) <[email protected]>; [email protected]; [email protected] >>> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lo
signature.asc
Description: PGP signature
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
