Task #2235
closedDefine maximum time for which Nonce+Name association should be kept
0%
Description
Right now, NDN protocol doesn't define such time frame, but we must define such a period. This at least should be implementation feature of NDN, otherwise it could cause problems to applications.
Updated by Junxiao Shi almost 10 years ago
- Category set to Tables
- Start date deleted (
11/26/2014)
I don't think this is necessary.
Applications (or their libraries) are expected to generate random Nonces where the chance of repeating is low.
Please describe what problem could be caused to a well-designed application.
The only way to provide such guarantee is to add a timestamp to every Dead Nonce List entry.
This triples the memory usage of Dead Nonce List, contradicts its design goal, and voids all memory-saving techniques applied in the design.
Updated by Junxiao Shi almost 10 years ago
- Target version deleted (
v0.3)
20150202 conference call decides to delete "Target Version", because there's an architecture discussion about making Nonce optional and using another method for loop detection.
Updated by Junxiao Shi over 1 year ago
- Is duplicate of Feature #5166: Make DeadNonceList lifetime configurable added
Updated by Davide Pesavento over 1 year ago
Junxiao Shi wrote in #note-1:
The only way to provide such guarantee is to add a timestamp to every Dead Nonce List entry.
This triples the memory usage of Dead Nonce List
Why triple? A DNL entry is 8 bytes. With a granularity of 500 ms, a 4-byte timestamp would be more than enough. Even accounting for alignment/padding, it's still only a 2x increase to 16 bytes per entry. What am I missing?
Updated by Junxiao Shi over 1 year ago
DNL entry used to be uint32.
ndn::time::SteadyClock::TimeStamp
is uint64.
When we naively stick a timestamp into the DNL entry, it's triple memory usage.
Updated by Davide Pesavento over 1 year ago
huh? Entry
has been a uint64_t
since the very beginning.
But regardless of what it used to be, NDN TR 0077 that was just published contains the same incorrect claim.