[Nfd-dev] strange results

[Dave Oran (oran)]

Given that any Interest arriving after a PIT entry has been satisfied (or timed out) has the hazard of re-creating the PIT and getting processed when it shouldn’t, the “DeadNonceList” entries have to persist for at least the MPL (maximum packet lifetime) of the network. In the IP world, various pathologies can cause this period to be very long; on the order of minutes. What’s the proposed DeadNonce timer for NFD? What’s the worst case memory pressure? - seems like it could be gigantic for a high-speed router. Are there replay attacks that can cause the DeadNonceList to grow without bound?

Some folks have argued this isn’t an implementation question so much as an architecture question around the use of nonces for loop detection in the first place.

DaveO.

> On Mar 1, 2015, at 11:21 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
> 
> Junxiao,
> 
> Thank you very much for the explanation and finding the root cause of the problem.  It is causing wild oscillations in the NDNPing delays (switches back and forth between the best path and worse paths back and forth) since the measurements that the strategy is based on were wrong.  I hope this could be fixed as soon as possible since we need the correct results for our paper.
> 
> 
> Conceptually the solution requires duplicate suppression (at least for some time) after a PIT entry has been satisfied.  I thought the DeadNonceList was designed for this purpose.  If you check the DeadNonceList before the PIT entry, then you'll detect the duplicate easily.   
> 
> However, if you do not want to check the DeadNonceList first (for whatever reason I don't understand), the current Interest processing flow has a couple issues if I understand correctly:
> 
> 1. the current logic assume that there's no need to record a dead nonce if the PIT entry is satisfied.  Obviously the example shows that although there's no danger of interest looping, there can be other dangers, e.g., the wrong measurements shown in the example.
> 
> 2. the in-record and out-record were deleted when the PIT entry is satisfied.  This causes problems since the current logic checks these things before checking the DeadNonceList.
> 
> So to fix the above, the code needs to (a) record the dead nonce regardless of whether the PIT entry is satisfied and also (b) check the DeadNonceList even after a PIT entry is satisfied.
> 
> Thanks a lot.
> 
> Lan
> 
> On Mar 1, 2015, at 12:53 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
>> Hi Lan
>> 
>> Trace of CSU node has:
>> 	• 5159.119 interestFrom UCLA
>> 	• 5159.140 interestTo MEMPHIS
>> 	• 5159.179 interestFrom UMICH
>> 	• 5159.245887 dataFrom MEMPHIS
>> 	• 5159.262 dataTo UCLA
>> 	• 5159.345243 interestFrom UIUC
>> 	• 5159.359 dataTo UIUC
>> 
>> Here's what happens:
>> 
>> 5159.119 upon receiving packet 1, new PIT entry is created with in-record of UCLA face
>> 5159.140 Interest is forwarded to MEMPHIS as packet 2; out-record of MEMPHIS face is created
>> 5159.179 packet 3 arrives, but it's suppressed due to duplicate Nonce in PIT entry
>> 5159.245887 packet 4 arrives and satisfies the PIT entry; straggler timer is set to erase the PIT entry at 5159.345887
>> 5159.262 Data is returned to UCLA as packet 5, but not UMICH because packet 2 was suppressed; in-records and out-record of MEMPHIS face are deleted; Nonce is not inserted to DeadNonceList because there's no risk of looping (see spec for exact condition)
>> 5159.345243 packet 6 arrives and cancels the straggler timer; it hits ContentStore and is not forwarded
>> 5159.345887 PIT entry won't be deleted now because straggler timer was cancelled by packet 6
>> 5159.359 Data from ContentStore is returned to UIUC as packet 7
>> 
>> 
>> The problematic step is: "in-records and out-record of MEMPHIS face are deleted".
>> Originally, PIT entry has a NonceList data structure to detect duplicate Nonces. Deleting in-records won't affect duplicate Nonce detection.
>> When DeadNonceList is introduced, the PIT NonceList is dropped, and PIT entry would report a duplicate Nonce only if any in-record or out-record contains a duplicate Nonce.
>> This assumes that in-records are retained before straggler timer expires, but forwarding pipelines are not able to fulfill this assumption.
>> 
>> This issue is tracked as Bug 2592.
>> Root cause is found, but I need to think about the design.
>> 
>> Yours, Junxiao
>> 
>> On Sat, Feb 28, 2015 at 11:02 PM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
>> csu/dump.0csu:1425075159.119112 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
>> csu/dump.4csu:1425075159.140391 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
>> csu/dump.6csu:1425075159.179620 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
>> csu/dump.4csu:1425075159.245887 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
>> csu/dump.0csu:1425075159.262268 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
>> csu/dump.5csu:1425075159.345243 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
>> csu/dump.5csu:1425075159.359534 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
>> 
>> Seems that CSU was not doing duplicate Interest suppression correctly.   The Interest from UIUC to CSU received at time 1425075159.345243 should have been dropped because it's a duplicate of the earlier Interest from UCLA to CSU received at time 1425075159.119112, but it was not and instead brought data back.  The time difference between the two Interests is 226ms.  I'm not sure how the duplicate suppression is implemented.  Someone more familiar with the forwarding pipeline please help explain the above trace.  Thanks.
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev