Project

General

Profile

Actions

Task #2235

closed

Define maximum time for which Nonce+Name association should be kept

Added by Alex Afanasyev over 9 years ago. Updated 8 months ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
Tables
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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 open0 closed)

Is duplicate of NFD - Feature #5166: Make DeadNonceList lifetime configurableNew

Actions
Actions #1

Updated by Junxiao Shi over 9 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.

Actions #2

Updated by Junxiao Shi about 9 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.

Actions #3

Updated by Junxiao Shi over 2 years ago

  • Tags set to DeadNonceList
Actions #4

Updated by Junxiao Shi 8 months ago

  • Is duplicate of Feature #5166: Make DeadNonceList lifetime configurable added
Actions #5

Updated by Junxiao Shi 8 months ago

  • Status changed from New to Duplicate
Actions #6

Updated by Davide Pesavento 8 months 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?

Actions #7

Updated by Junxiao Shi 8 months 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.

Actions #8

Updated by Davide Pesavento 8 months 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.

Actions

Also available in: Atom PDF