[Nfd-dev] problem with selector for implicit digest?

Thompson, Jeff jefft0 at remap.ucla.edu
Sat Dec 12 07:14:24 PST 2015


I tested in PyNDN and I confirm the same problem: NFD does not match an incoming data packet with an interest in the PIT which has an implicit digest component (but it does match from the content store).

Looking at the NFD code, Pit::findAllDataMatches calls m_nameTree.findAllMatches(data.getName(), …) which does a longest prefix match of the data name to the interest name.
https://github.com/named-data/NFD/blob/5e5e44518286e89a0092ea0ad93c22e64128bdd2/daemon/table/pit.cpp#L97

But the interest name with the implicit digest component in the PIT is longer than the data name, so how can LPM match it? Should NFD strip the implicit digest component before putting the interest name in the PIT’s name tree?

- Jeff T

On 2015/12/11, 16:12:07, "Nfd-dev on behalf of christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>" <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu> on behalf of christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>> wrote:

I'm hitting a wall with nfd behavior when it comes to the implicit digest.

a) What is working correctly:
- first retrieve a packet by ordinary name
- compute the digest of the received packet
- then retrieve the same packet, but this time with the
   special digest component appended and MaxSuffix=0
- this works, the data will probably now be served from the CS
(digest is a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d)

b) What is not working:
- directly retrieve another packet with its (other) name and including
   the special digest component for that data, and MaxSuffix=0
- nfd accepts this request and forwards it upstream
- nfd receives that data packet
- but the received data is not delivered to the downstream
   client (timeout of ndnpeek although I can see that nfd
   received the right packet).
(digest is 65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623)

The content comes in both cases from an upstream node (running
ccn-lite), see the topology below.

One potential catch is that the two names are almost identical:

The name in step a) is
/ndn/ch/unibas/repo256/movie7.mp4/_

The name in step b) is
/ndn/ch/unibas/repo256/movie7.mp4

Is this a bug in PIT matching? Or has the second data object an internal
problem that lets nfd refuse it (see the attached packet)? Below I also
add the command line logs, FYI.

Best, christian

---

# topology

   ndnpeek --> nfd (UDP 6363) --> ccn-lite-relay (UDP 3636) --> ccn-lite-repo256 (UDP 7777)


# case a), showing correct behavior

tschudin at cs-ndn-testbed1:~$ ndnpeek -v /ndn/ch/unibas/repo256/movie7.mp4/_ >pkt-1.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/_
DATA, RTT: 5ms

tschudin at cs-ndn-testbed1:~$ shasum -a 256 pkt-1.bin
a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d  pkt-1.bin

tschudin at cs-ndn-testbed1:~$ ndnpeek -v /ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d
pkt-2.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d
DATA, RTT: 5ms

tschudin at cs-ndn-testbed1:~$ cmp pkt-1.bin pkt-2.bin

tschudin at cs-ndn-testbed1:~$


# case b), showing the error

tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0 /ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb2adf74a4572b100c5f12885 >pkt-3.bin
INTEREST: /ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb2adf74a4572b100c5f12885?ndn.MaxSuffixComponents=0
TIMEOUT

tschudin at cs-ndn-testbed1:~$


# Log file captured with tcpdump (case b)

tschudin at cs-ndn-testbed1:~$ sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or udp port 7777' >traffic.log &
[2] 20530
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes

tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0 /ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623 >pkt-3.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623?ndn.MaxSuffixComponents=0
TIMEOUT

tschudin at cs-ndn-testbed1:~$ fg
sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or udp port 7777' > traffic.log
^C6 packets captured
12 packets received by filter
0 packets dropped by kernel

tschudin at cs-ndn-testbed1:~$ less traffic.log
00:47:08.269244 IP cs-ndn-testbed1.cs.unibas.ch.6363 > cs-ndn-testbed1.cs.unibas.ch.3636: UDP, length 87
00:47:08.270061 IP localhost.3636 > localhost.6363: UDP, length 87
00:47:08.270181 IP localhost.6363 > localhost.3636: UDP, length 100
00:47:08.270362 IP localhost.3636 > localhost.7777: UDP, length 87
00:47:08.271063 IP localhost.7777 > localhost.3636: UDP, length 3862
00:47:08.271227 IP cs-ndn-testbed1.cs.unibas.ch.3636 > cs-ndn-testbed1.cs.unibas.ch.6363: UDP, length 3862

traffic.log (END)


# log from the ccn-lite relay (which links to the upstream repo256, both running
# on the same machine as nfd but using UDP ports 3636 and 7777, respectively)

[D] 100.1443: ccnl_core_RX ifndx=0, 87 bytes
[D] 100.1443:   face 9, peer=192.43.193.111/6363
[I] 100.1444:   incoming interest=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013 from=192.43.193.111/6363
[D] 100.1444:   searching in CS
[D] 100.1446:   created new interest entry 0x1364f70 (prefix=/ndn/ch/unibas/repo256/movie7.mp4)
[D] 100.1446: ccnl_interest_propagate
[D] 100.1447:   ccnl_interest_propagate, fwd==0x13650d0
[I] 100.1447:   outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4> to=127.0.0.1/6363
[D] 100.1449: udp sendto(87 Bytes) to 127.0.0.1/6363 returned 87/0
[D] 100.1450:   ccnl_interest_propagate, fwd==0x100e1f0
[I] 100.1450:   outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4> to=127.0.0.1/7777
[D] 100.1450: udp sendto(87 Bytes) to 127.0.0.1/7777 returned 87/0
[D] 100.1450: ccnl_core_RX ifndx=0, 100 bytes
[D] 100.1451:   face 2, peer=127.0.0.1/6363
[I] 100.1457:   ndnlp packet
[D] 100.1458: ccnl_core_RX ifndx=0, 3862 bytes
[D] 100.1458:   face 6, peer=127.0.0.1/7777
[I] 100.1458:   incoming data=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013 from=127.0.0.1/7777
[I] 100.1458:   outgoing data=</ndn/ch/unibas/repo256/movie7.mp4>ndn2013 to=192.43.193.111/6363
[D] 100.1460: udp sendto(3862 Bytes) to 192.43.193.111/6363 returned 3862/0
[D] 100.1460:   adding content to cache

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


More information about the Nfd-dev mailing list