[Ndn-interest] Renumbering name component types?

[Lan Wang (lanwang)]

Hi Junxiao,

Thank you for your input.  As Lixia suggested, we will not make a decision until we have reviewed the pros and cons.  Alex agreed to send a summary of the pros and cons.  Let’s wait for Alex’s summary.

Lan

On Jul 23, 2021, at 11:45 AM, Junxiao Shi via Ndn-interest <ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and trust the content is safe.

Dear folks

In 2021-07-23 NFD call, it was brought up that several name component types have the same TLV-TYPE number assignments as TLV elements in the network layer:

  *   0x22 (34 in decimal) is both ByteOffsetNameComponent and HopLimit in the network layer.
  *   0x24 (36 in decimal) is both TimestampNameComponent and ApplicationParameters in the network layer.

https://redmine.named-data.net/projects/ndn-tlv/wiki/NameComponentType
https://named-data.net/doc/NDN-packet-spec/current/types.html

It was proposed that all of the name component types should be renumbered to a different range, because "TLV-TYPE numbers for name components and network layer should be unique".
Moreover, it was proposed that not only the above two conflicting numbers should be moved, but also the other numbers in the currently assigned 0x20 ~ 0x25 range.
I am strongly against this proposal.

First, TLV-TYPE numbers for name components and in the network layer are in distinct numbering space.
They do not have an actual conflict in the protocol and implementations: a packet parser is expected to know whether it is reading a name component or not.
In other words, this renumbering proposal "improves perceived cleanness", but does not solve a bug in the protocol.

Second, Naming Convention rev2 was published in 2019, and a number of applications have already adopted it.
For example, I current operate the largest video streaming service on the NDN testbed, and all the video packets have been encoded with TLV-TYPE numbers specified in Naming Convention rev2, and in particular 0x23 VersionNameComponent and 0x21 SegmentNameComponent.
If the Naming Convention is changed once again, it would create one of two undesirable scenarios:

  *   I would have to re-encode all video packets.
  *   I could stay with rev2 and not move to rev3. This causes my packets to become incompatible with tools such as ndncatchunks.

I would be slightly less against this proposal, if it only renumbers 0x22 and 0x24, without changing number assignments of other name component types.

Yours, Junxiao
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20210725/83541f62/attachment.html>