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

Sat Dec 12 13:03:08 PST 2015

As a point of historical interest, in  CCNx 0.8, all matching against a Content Object was done via the so-called “full name.”  The full name of a content object is its name plus its implicit digest.  And only in this sense does the MaxSuffixComponents/MinSuffixComponents make sense.

If one does not always append the implicit digest, then one could run in to situations where someone conjures up a name with a fake terminal digest component which could match an Interest with a digest component.  For example, I have a content object with real digest 0x123.  I create a name /foo/bar/digest=0xFFF.  The full name should be /foo/bar/digest=0xFFF/digest=0x123.  If one does not always append the implicit digest, then the content object could match an interest for /foo/bar/digest=0xFFF, particularly if an implementation was sloppy on how it handled the min/max suffix components (which is often misunderstood).

Marc

On Dec 12, 2015, at 7:14 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

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<http://cs-ndn-testbed1.cs.unibas.ch>.6363 > cs-ndn-testbed1.cs.unibas.ch<http://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<http://cs-ndn-testbed1.cs.unibas.ch>.3636 > cs-ndn-testbed1.cs.unibas.ch<http://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

---
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

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