[Nfd-dev] strange results

[Junxiao Shi]

Hi Lan

Trace of CSU node has:

   1. 5159.119 interestFrom UCLA
   2. 5159.140 interestTo MEMPHIS
   3. 5159.179 interestFrom UMICH
   4. 5159.245887 dataFrom MEMPHIS
   5. 5159.262 dataTo UCLA
   6. 5159.345243 interestFrom UIUC
   7. 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
<http://redmine.named-data.net/issues/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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150228/03be6fa7/attachment.html>