1 / 15

Dead Nonce List

Dead Nonce List. Junxiao Shi 2014-10-04. Bug 1953: persistent loop with short InterestLifetime. At this point, A does not know this Interest is looped, because PIT entry is deleted when in-record expires. A would send Interest to B again, causing persistent loop.

honorato-nguyen
Download Presentation

Dead Nonce List

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dead Nonce List Junxiao Shi 2014-10-04

  2. Bug 1953: persistent loop with short InterestLifetime At this point, A does not know this Interest is looped, because PIT entry is deleted when in-record expires. A would send Interest to B again, causing persistent loop. in-record: face D, Nonce 204 out-record: face B, Nonce 204 expires at 170 Interest Nonce=204 lifetime=150 D A delay=20 delay=100 B delay=20 C delay=100 t=240 t=0 t=20 t=120 t=170 t=220

  3. Why bug 1953 happens? • Seen Nonces are stored in PIT entry only. • Lifetime of PIT entry: • If Interest has been satisfied, PIT entry is kept for straggler timer (=100ms). • If Interest is unsatisfied, PIT entry is kept until all in-records expire (=InterestLifetime). • When InterestLifetime is shorter than the delay of a cycle, PIT entry could be deleted before Interest completes a loop, so that the forwarder is unable to detect the looping Interest.

  4. Can we keep PIT entries for longer? • Keeping PIT entries for longer can fix the bug. • Cycles in the network can have high delays, up to several seconds. • PIT entry contains the whole Interest packets and other information. Storage overhead is too high to keep all PIT entries for several seconds. • Keeping only unsatisfied PIT entries for several seconds isn't sufficient: think MustBeFresh=yes and FreshnessPeriod=0.

  5. How does ccnd prevent such loops? • ccnd has a global Nonce Table. • Each entry has: Nonce, timestamp. • Note: Name is not in the Nonce Table entry. • An entry is kept for 6 seconds, judged by timestamp. • Duplicate Nonce detection solely relies on Nonce Table. • NFD cannot do the same. • ccnd Nonce is 6 octets. • NDN-TLV Nonce is 4 octets. • There's a higher probability to have a collision of 4-octet Nonce.

  6. What about global Nonce Table with Name? • NDN-TLV requires (Name, Nonce) tuple to be unique. • Global Nonce Table with (Name, Nonce) in entries can fix the bug. • But its overhead is only slightly lower than keeping PIT entries for several seconds, because Names can be long.

  7. Idea: hash the Name • Have a global table of (Name, Nonce), but store Name as a hash. • Use a cheap hash function, so it's faster to compute. Cryptography-secure hash is unnecessary. • Use a short hash value, so the table consumes less memory. 4-octet is sufficient. • Are there collisions? • Yes, all hash functions have collisions. • But the probability of having a collision of (4-octet hash, 4-octet Nonce) is rather low. • Alternatively, use a 8-octet hash covering both Name and Nonce. • Benefit: chance of collision doesn't depend on the randomness of Nonce. (NDN-TLV spec doesn't require Nonce to be random) • This requires a hash function that can efficiently take two inputs.

  8. Get rid of the timestamp • Each entry has 4-octet Name hash and 4-octet Nonce, and –a 8-octet timestamp? • It's unnecessary to ensure every entry is kept for an exact duration, so we can get rid of the timestamp. • Suppose every entry should be kept for 6 seconds: • Every second, insert a time marker: an entry between (0,0) and (0,15). • The time marker has the same type as a regular entry. The probability of having a pre-determined hash value, in this case 0, is rather low. • Periodically count time markers in the container. • Adjust the size of container to make the number of time markers near 6.

  9. Background: Loop vs Multi-path NonceA NonceB • A duplicate Nonce detects either a loop or a multi-path arrival. • NonceBis never sent out, duplicate means multi-path arrival • NonceA has been sent out, duplicate means either loop or multi-path arrival, and these two reasons are indistinguishable A E R multi-path B loop multi-path G D F

  10. Do we need to insert every Nonce? • No. Only outgoing Nonces need to be inserted, because only outgoing Nonces can cause loops. • But we still need to detect multi-path arrival in order to return Data on only one path. Therefore, PIT entry should still store Nonces for this purpose. • Since PIT entries are already storing Nonces, the global table only needs to store Nonces eliminated from PIT entries, aka "dead" Nonces. Therefore, the global table is called dead Nonce list.

  11. Take chances on ContentStore • If a Data satisfies a PIT entry and is admitted to the ContentStore, looping Interests can be satisfied by cached Data if: • Interest doesn't have MustBeFresh=yes selector, OR • Data FreshnessPeriod is long enough to cover delay of a cycle • We can take chances by not inserting Nonces from such a PIT entry. • The assumption is that the Data isn't evicted before Interest is looped back. • In case Data is evicted, Interest would loop once again. If Data is retrieved this time, hopefully it would stay in CS until after Interest is looped back once again. If Data cannot be retrieved, the Nonce goes into dead Nonce list to stop the loop.

  12. A formal spec • The Dead Nonce List is a global container in NFD. • Each entry in this container stores CityHash64WithSeed(Name, Nonce). • The existence of an entry can be queried in logarithmic time. • The container is first-in-first-out, and the size is maintained such that the first entry is approximately MAX_LOOP_TIME old. • PIT entry stores one Nonce per in-record and per out-record. • There is no Nonce List on PIT entry.

  13. A formal spec • When an out-record is being deleted or its Nonce is being overwritten, the old Nonce is inserted to dead Nonce list. • Exception: if Interest doesn't have MustBeFresh or Data FreshnessPeriod is greater than MAX_LOOP_TIME, no insertion is needed. • Incoming Interest pipeline detects duplicate Nonce by looking at in-records, out-records, and dead Nonce list. • A duplicate Nonce in out-record or dead Nonce list indicates either loop or multi-path arrival but they are indistinguishable. • A duplicate Nonce only in in-record indicates multi-path arrival.

  14. Setting MAX_LOOP_TIME • MAX_LOOP_TIME determines how long an entry stays in dead Nonce list. • Too large: more memory consumption. • Too small: higher risk of looping. • Default setting: 6 seconds • taken from ccnd • If a loop takes longer than (InterestLifetime + MAX_LOOP_TIME), it cannot be detected and would loop forever. Hopefully this doesn't happen in a realistic network topology.

  15. Role of straggler timer • Before introducing dead Nonce list, the straggler timer is used for loop detection and measurements purposes. • Now loop detection is handled by dead Nonce list. • The straggler timer is still needed to detect duplicate Nonce due to multi-path arrival, and to facilitate measurements. • If we could prove that suppressing Data in multi-path arrival is undesirable, and the active strategy doesn't need measurements, we could disable straggler timer.

More Related