Task #2235
closed
Define maximum time for which Nonce+Name association should be kept
Added by Alex Afanasyev almost 10 years ago.
Updated over 1 year ago.
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.
Related issues
1 (1 open — 0 closed)
- 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.
- 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.
- Tags set to DeadNonceList
- Is duplicate of Feature #5166: Make DeadNonceList lifetime configurable added
- Status changed from New to Duplicate
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?
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.
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.
Also available in: Atom
PDF
Updated by 
Updated by