[Nfd-dev] Help needed with debugging duplicate Nonce

Junxiao Shi shijunxiao at email.arizona.edu
Tue Jul 12 10:58:25 PDT 2016


Hi Lan

Look at this topology:
A---B
 \ /
  C
Assume every link has the same delay, and the processing delay at each node is zero.

When C sends the same Interest to both A and B, A and B would forward the Interest to each other, and get Nack-Duplicate from each other.
Per ChronoSync protocol, the applications on A and B should express Interests with the same name. Since A and B are symmetric, let’s look at A.
There could be three different timings:

TIMING0 AppA expresses the Interest before C’s Interest arrives at A.
If we relabel A->C B->A C->B, it becomes either TIMING1 or TIMING2.

TIMING1 AppA expresses the Interest after C’s Interest has been forwarded to B, but before B responds Nack-Duplicate.
The duration between A forwarding C’s Interest to B and A receiving Nack-Duplicate from B is most likely shorter than the suppression interval, so appA’s Interest would be suppressed.
When Nack-Duplicate against C’s Interest arrives from B, strategy at A should send appA’s Interest to B.

TIMING2 AppA expresses the Interest after B responds Nack-Duplicate.
When Nack-Duplicate against C’s Interest arrives from B, strategy at A should not return the Nack to C, because appA is another upstream which has not Nacked.
When appA expresses the Interest, strategy at A should not suppress this Interest, because the sole pending upstream (appA) is now a downstream. The strategy should forward the Interest to both B and C.


When the strategy behaves as what I describe above, everyone should be getting Data.

Yours, Junxiao



From: Lan Wang (lanwang)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160712/658b5b03/attachment.html>


More information about the Nfd-dev mailing list