[Nfd-dev] Help needed with debugging duplicate Nonce

Tue Jun 28 08:48:35 PDT 2016

Have attached proof for the said observation.

tmp-localhost_6_27$ grep --color=always 927845950 */ndndump* | sort -t: -k2
c/ndndump.c-eth0_1.0.0.10.pcap:1467054254.052399 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth1_1.0.0.9.pcap:1467054254.052424 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
c/ndndump.c-eth1_1.0.0.6.pcap:1467054254.052428 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth1_1.0.0.5.pcap:1467054254.052436 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.955331 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.955348 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950

1) c to b

2) c to a

3) b to a

4) a responds with duplicate NACK

Meanwhile I will also try to test Junxiao's suggestion by forcing communication over TCP and make sure that this is because of local sync expressing the same interest.

Ashlesh

________________________________
From: Lan Wang (lanwang)
Sent: Tuesday, June 28, 2016 5:43 AM
To: Junxiao Shi
Cc: Ashlesh Gawande (agawande); nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce

Junxiao,

Yes, we observe the same interest forwarding behavior when using /localhop.  I think the reason why the /localhop interest is forwarded beyond one hop is because every node is expressing the same interest -- in ChronoSync when every node reaches consistency, they have the same digest so they have the same sync interest.

We tried to use /localhop to force the sync interest to be one hop.  Otherwise, as you can see in the trace, when the sync interest is forwarded, it causes duplicate NACK and basically it cancels that sync interest.  In order for sync to work correctly, we need to have a pending sync interest in each direction of a link, if the sync interest is canceled by the NACK, then if a node has a change, it cannot respond to the pending sync interest and therefore cannot propagate any changes.  This is what we observed when running NLSR after duplicate NACK was implemented.  There are a lot of duplicate NACKs and the convergence of NLSR is affected.

This is a problem that will affect every protocol that uses sync.

Why was the forwarding of /localhop becomes non local hop if the receiving node is expressing the same interest?

Lan

On Jun 27, 2016, at 2:59 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Lan

The Interest name is the snippet is: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e
There's no /localhop is this name.

In general, if you find NFD forwarding a /localhop Interest, this means a local application is expressing the Interest.
In A-B-C linear topology, when A expresses an Interest and is forwarded to B, B usually does not forward it to C. However, if a local application on B expresses an Interest with same Name+Selectors+Link, B can forward this Interest to C.
If you are suspecting this problem, you may force the application on B to connect to local NFD via TCP by setting `transport=tcp4://127.0.0.1:6363` in $HOME/.ndn/client.conf, and then you'll be able to run tcpdump on the loopback interface and observe whether any local application is expressing the Interest.

Yours, Junxiao

On Mon, Jun 27, 2016 at 11:30 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
We used /localhop in the name.  Why were the packets forwarded beyond one hop?

Lan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.a-eth0_1.0.0.1.pcap
Type: application/vnd.tcpdump.pcap
Size: 17459 bytes
Desc: dump.a-eth0_1.0.0.1.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.a-eth1_1.0.0.5.pcap
Type: application/vnd.tcpdump.pcap
Size: 20527 bytes
Desc: dump.a-eth1_1.0.0.5.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.b-eth0_1.0.0.2.pcap
Type: application/vnd.tcpdump.pcap
Size: 17459 bytes
Desc: dump.b-eth0_1.0.0.2.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.b-eth1_1.0.0.9.pcap
Type: application/vnd.tcpdump.pcap
Size: 18852 bytes
Desc: dump.b-eth1_1.0.0.9.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.c-eth0_1.0.0.10.pcap
Type: application/vnd.tcpdump.pcap
Size: 18852 bytes
Desc: dump.c-eth0_1.0.0.10.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.c-eth1_1.0.0.6.pcap
Type: application/vnd.tcpdump.pcap
Size: 20527 bytes
Desc: dump.c-eth1_1.0.0.6.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment-0005.bin>