[Nfd-dev] Nack receive duplicate on ndnperf

[Junxiao Shi]

Hi Ishita


>
> I am trying to download a file using ndnperf client on 10 different nodes
> and some of them ressult in incomplete downloads. On simply running a
> "ndnperf prefix" to test the network stats, I see some of the nodes return
> "Nack receive : Duplicate" after one point.
>

A Nack~Duplicate occurs when a node receives two Interests with the same
nonce.

I have 10 containers running on the the node C. Assume each of those 10
> containers is trying to download a file from the producer. Some of them
> have incomplete download.
>

So the topology is: S—R—W—C0~C9.
S is the producer. R is an NDN forwarder. W is an Ethernet switch. C0~C9
are ten consumers.

2. The ethernet faces are automatically available on the FIB. As seen from
> the topology, R has 2 physical ethernet faces and C has one. I add route
> for outgoing interface per node(R and C). I looked at the corresponding
> ethernet face id from "nfdc face" command. Then added "route using "nfdc
> route add prefix /edu/ishita nexthop <faceid>;" command.
>

NFD 0.6.2 prohibits transmitting a Nack on a broadcast or ad hoc wireless
face. You can confirm these Ethernet faces have one of these attributes by
‘nfdc face’. (note: these attributes are incorrectly labeled as
“multi-access” and “ad hoc”, see https://redmine.named-data.net/issues/4282
).
This means, the Nack~Duplicate seen by the consumer must come from the
consumer node itself.

One way for this to happen is:
1. Since C0~C9 are containers in the same physical box, they could share a
random seed.
2. If C0~C9 consumers are somehow launched simultaneously, the ndn-cxx
non-secure random number generator might be seeded with the same value.
Consequently, two or more consumers would be generating the same sequence
of nonces.
3. Suppose forwarder C1 first receives an Interest from the network
interface, and then receives another Interest with same name and nonce from
its local consumer, it would tell consumer Nonce~Duplicate.

You can confirm this hypothesis with tcpdump.
1. Make consumer connect to NFD via TCP loopback rather than Unix.
2. Run tcpdump on loopback interface of each container.
3. Analyze the pcap to see whether there are duplicate nonce across
containers.

If this hypithesis is confirmed, one solution is to start consumers at
different times. If you want to use a randomized delay to achieve this,
you’ll need to pick the delay from outside the container, otherwise you’ll
get the same delay as well!
Please do consult the technical support of your container technology
provider, and see whether they have any suggestions on the random seeding
device.

Interestingly, ndn-cxx seeds its random number generator with a single
32-bit integer picked from the random device:
https://github.com/named-data/ndn-cxx/blob/ndn-cxx-0.6.3/src/util/random.cpp#L58
The recommended way is to use a random sequence itself:
http://www.pcg-random.org/posts/cpp-seeding-surprises.html
However, that may or may not help in your case, because the random sequence
may as well be duplicating across containers.

3. I did not add any forwarding straregy of my own. The following default
> strategies are being used. NFD Version 0.6.2 on all nodes.
>
>    prefix=/ strategy=/localhost/nfd/strategy/best-route/%FD%05
>
> The effective strategy should be best-route v5.


> 4. *Comment*: What I also observe is file transfer with NDN over UDP is
> faster and better than compared to NDN over ethernet with intermittent
> downloads only in case of NDN over ethernet.
>

This is possibly https://redmine.named-data.net/issues/2441

Yours, Junxiao

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20181220/1b85130e/attachment.html>