[Ndn-interest] Renumbering name component types?

Lan Wang (lanwang) lanwang at memphis.edu
Sun Jul 25 12:43:33 PDT 2021

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.


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.


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>

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

More information about the Ndn-interest mailing list