Project

General

Profile

Feature #4895

Limit TLV-TYPE range

Added by Junxiao Shi 9 months ago. Updated 8 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Start date:
Due date:
% Done:

100%

Estimated time:
1.00 h

Description

Current packet format allows full 64-bit range for TLV-TYPE, but this is causing implementation difficulty and bugs such as #4726.
The protocol should limit TLV-TYPE to [1, 2^32-1] range.
This is a trade-off between giving enough numbers for applications and simplifying implementations.


Related issues

Related to ndn-cxx - Bug #4726: Block class mishandles type == 0xffffffff (was: NFD crashes on unexpected input)Closed

Actions

History

#1

Updated by Junxiao Shi 9 months ago

  • Related to Bug #4726: Block class mishandles type == 0xffffffff (was: NFD crashes on unexpected input) added
#2

Updated by Davide Pesavento 9 months ago

  • Description updated (diff)
#3

Updated by Davide Pesavento 9 months ago

TLV-TYPE 0 (zero) is currently unused, can we reserve it to indicate an invalid type that MUST NOT appear on the wire? That way we can keep a 32-bit type as commonly implemented today.

#4

Updated by Davide Pesavento 9 months ago

And we can restrict TLV-LENGTH to 32 bits as well (all 32-bit values are valid in this case).

#5

Updated by Junxiao Shi 9 months ago

Limiting TLV-LENGTH was discussed at 20190325 call and was rejected.

I don’t see a reason to require [2^31,3^32) range for TLV-TYPE. Having 231 numbers is more than enough.

#6

Updated by Davide Pesavento 9 months ago

Junxiao Shi wrote:

Limiting TLV-LENGTH was discussed at 20190325 call and was rejected.

The general idea was NOT rejected. In fact, nobody was opposed to limiting TLV-LENGTH, we just couldn't reach a consensus on what exact range to limit it to.

I don’t see a reason to require [2^31,3^32) range for TLV-TYPE. Having 231 numbers is more than enough.

I could make the same argument for 230 or 229 .... It is much more natural to use a power-of-two such as 32. When we decided to use 31 bits I didn't realize that TLV-TYPE 0 is unused. Using 32 bits, with 0 reserved to indicate an invalid TLV, makes a lot more sense now.

#7

Updated by Junxiao Shi 8 months ago

  • Description updated (diff)
  • Status changed from New to In Progress
  • Assignee set to Junxiao Shi

20190403 call decides to use 0 as an indicator of invalid TLV-TYPE. All other uint32 numbers are valid TLV-TYPE.

#8

Updated by Junxiao Shi 8 months ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 80
#9

Updated by Junxiao Shi 8 months ago

There's a suggestion about:

Type code 0 (zero) is reserved to indicate an invalid TLV element and ... should be discarded / treated as ...

I'm reluctant to require receiver to discard any packet with zero at TLV-TYPE position. In fact, my vision is to use zeros as padding bytes when necessary, so that packets can be more efficiently encoded in producers and more efficiently modified by forwarder.

#10

Updated by Davide Pesavento 8 months ago

Junxiao Shi wrote:

There's a suggestion

It's not a suggestion. It's a clarification of what has already been decided.

I'm reluctant to require receiver to discard any packet with zero at TLV-TYPE position. In fact, my vision is to use zeros as padding bytes when necessary, so that packets can be more efficiently encoded in producers and more efficiently modified by forwarder.

I'm not following here... what does padding have to do with this? You already cannot send a TLV with type == 0, it would be treated as unrecognized.

#11

Updated by Junxiao Shi 8 months ago

The "padding" thing is to have the decoder ignore any 0x00 where a TLV element is ignored, so that encoder can use any length of 0x00 octets as padding.
However, I think whether or not declaring 0x00 as invalid TLV-TYPE does not change whether padding could be added in the future, so I won't pursue this now.

#12

Updated by Junxiao Shi 8 months ago

  • Status changed from Feedback to Closed
  • % Done changed from 80 to 100

Also available in: Atom PDF