Feature #4432
closed
Reserve NDNLP header type for PIT token
100%
Description
NIST fast forwarder project requires a 1-octet NDNLP header TLV-TYPE number for "PIT token" field.
PIT-TOKEN = PIT-TOKEN-TYPE TLV-LENGTH 1*32OCTET
The "PIT token" field is similar to "Interest digest" as described in #3333, but it is hop-by-hop and does not require universal agreement.
A downstream attaches one or more bytes as the TLV-VALUE of this field when transmitting an Interest. These bytes are opaque to the upstream.
When an upstream responds to this Interest with a Data or a Nack packet, it MUST attach a PIT token field with the same bytes.
The downstream MUST verify these bytes before assuming the Data/Nack matches the Interest.
This issue only reserves a TLV-TYPE number. It does not involve code changes on NFD or other projects.
Updated by Junxiao Shi almost 7 years ago
- Description updated (diff)
- Status changed from New to Resolved
NDNLPv2 rev25 reserves TLV-TYPE number 0x62 for PIT token.
Updated by Davide Pesavento almost 7 years ago
Are you going to contribute a minimal implementation of PIT token support in NFD, to allow interoperability?
Updated by Junxiao Shi almost 7 years ago
Are you going to contribute a minimal implementation of PIT token support in NFD, to allow interoperability?
Probably, but not under this issue.
Updated by Junxiao Shi over 6 years ago
- Blocks Feature #4532: Store and return PIT tokens from downstream added
Updated by Junxiao Shi over 6 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
Updated by Junxiao Shi over 5 years ago
- Description updated (diff)
From https://gerrit.named-data.net/#/c/ndn-cxx/+/5500/1/ndn-cxx/lp/fields.hpp@58:
why is it represented as a buffer rather than a uint64_t?
PitToken field is a non-empty buffer of arbitrary length, not of any particular length.
well, that probably wasn't a great idea then. Constructing and storing a Buffer (std::vector) isn't terribly efficient, even considering SBO. There is no need to make the definition overly generic. We should change the spec to limit the field to 8 bytes or whatever.
I disagree. While my current implementation uses 64-bit PIT tokens, I may potentially need longer tokens for:
- support of faster network speeds
- checksum within tokens, so that untrusted devices cannot insert malicious tokens
- hardware-assisted accelerations
Updated by Davide Pesavento over 5 years ago
We'll cross that bridge when we get there. You don't even know if you'll need more than 64 bits. Let's not add more overhead than strictly necessary for something we don't even know will be needed.
Updated by Alex Afanasyev over 5 years ago
Well... Using less efficient Buffer now would be future proof, on an odd chance that we will use longer tokens. On the other hand, we could switch to a different token type when such things happen. So, I suggest we simply update the spec for this specific token to be exactly 64bits and extensions in the future would use simply a different token type, if we get there.
Updated by Davide Pesavento over 5 years ago
Alex Afanasyev wrote:
Well... Using less efficient Buffer now would be future proof, on an odd chance that we will use longer tokens. On the other hand, we could switch to a different token type when such things happen. So, I suggest we simply update the spec for this specific token to be exactly 64bits and extensions in the future would use simply a different token type, if we get there.
+1
Updated by Junxiao Shi over 5 years ago
Well... Using less efficient Buffer now would be future proof, on an odd chance that we will use longer tokens.
Please prove Buffer is less efficient than alternative for short inputs.
Also, I have plans to use 2 or 4-byte tokens for IoT forwarders. There aren't many 1-octet link protocol TLV-TYPE numbers left for more tokens.
Therefore, I disagree with any protocol changes.
Updated by Davide Pesavento over 5 years ago
Junxiao Shi wrote:
Also, I have plans to use 4-byte tokens for IoT forwarders.
Which can definitely use a different header field (i.e. different TLV type, etc...), considering that the two use cases have no overlap. Also I have my doubts that you would use NDNLP for a constrained IoT network, given the encoding overhead in terms of packet size.
There aren't many 1-octet link protocol TLV-TYPE numbers left.
This is really a non issue.
Updated by Junxiao Shi over 5 years ago
I'm okay with defining a fixed 8-octet token type, in addition to any-length token type. Both types will be implemented and supported at the same time, in the same commit.
Updated by Junxiao Shi over 5 years ago
- Description updated (diff)
20190701 NFD call decides PIT token is to be limited to 32 octets, so that it can have bounded memory usage.
Updated by Davide Pesavento over 5 years ago
Can you add the definition to the NDNLPv2 wiki page?
Updated by Junxiao Shi over 5 years ago
Can you add the definition to the NDNLPv2 wiki page?
It's intentionally not included on that page, just like ndnSIM's HopCount tag isn't there.
TLV-TYPE number assignments are there.