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

Sat Dec 12 09:10:58 PST 2015

Jeff, thanks for this insight.

This seems to indicate that so far digest-based lookup was not used by 
anyone, and therefore now would be a good moment to revisit that part of 
the mechanics?

Since the beginning of ccn-lite I thought that the handling of the 
implicit digest was not elegant and will lead to implementation 
accidents. Conceptually it is a selector and should be handled there, 
instead of a name component.

One could even go a step further and reserve a special field for it in 
the interest (instead of inside the selector block) because it is a 
knock-out restriction: Any selector then becomes irrelevant.

Thoughts?

best, c

On Sat, 12 Dec 2015, Thompson, Jeff 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/t
> able/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"
> <nfd-dev-bounces at lists.cs.ucla.edu on behalf of 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=a3c19829edf901ff9d1a87f6da82af050a1cc30
> 2784b9b18ecd3812deef6795d
>       pkt-2.bin
> 
> INTEREST:/ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc30
> 2784b9b18ecd3812deef6795d
> 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=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb
> 2adf74a4572b100c5f12885 >pkt-3.bin
> INTEREST:/ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb
> 2adf74a4572b100c5f12885?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=65d5baf5960a4151ee64f8aa93ed19c90c5093230
> 8d3019848f23b2f59bc0623 >pkt-3.bin
> INTEREST:/ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c5093230
> 8d3019848f23b2f59bc0623?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
> 
> ---
> 
> 
>