[Nfd-dev] Troubleshooting interest path

[Junxiao Shi]

Hi Jeff

As Davide has already answered, ndndump
<https://github.com/named-data/ndn-tools/tree/master/tools/dump> and NDN
packet dissector for Wireshark
<https://github.com/named-data/ndn-tools/tree/master/tools/dissect-wireshark>
are
the best available tools.
If an application lacks logging capability (repo-ng in your example), there
are two techniques to observe packets to and from this application:

   - Force the application to connect to NFD over TCP. In ndn-cxx, you can
   set environ NDN_CLIENT_TRANSPORT=tcp4://127.0.0.1:6363 to change the
   default to TCP. Then, you can use ndndump or Wireshark to capture packets
   on the loopback interface.
   - Rename the Unix socket of NFD in nfd.conf. Have a "proxy" program
   listen on /var/run/nfd.sock, log all traffic to a file and also forward
   them to NFD's socket. socat <http://linux.die.net/man/1/socat> can be
   used as the proxy. The traffic log can then be analyzed with ndn-dissect
   <https://github.com/named-data/ndn-tools/tree/master/tools/dissect>.


CCNx-Trace <https://named-data.net/codebase/applications/ccnx-trace/> is a
traceroute tool for NDN platform 0.2 and earlier. When we design NFD, the
authors of CCNx-Trace confirm that CCNx-Trace can be ported to NFD without
special support from NFD. As per my understanding of CCNx-Trace, this claim
is true. However, even if CCNx-Trace is ported to NFD, it's ineffective in
revealing Interest/Data paths.

How CCNx-Trace works when you run CCNx-Trace client on Arizona router to
find path to UCLA: (I'm explaining with NFD terminology although the tool
is implemented for CCNx)

   1. Client expresses an Interest /trace/ndn/edu/ucla/app/<random1>.
   2. Trace daemon on Arizona (listening on /trace) receives this Interest,
   requests the FIB dataset, and finds that a longest prefix match for
   /ndn/edu/ucla/app would match FIB entry /ndn/edu/ucla. This FIB entry
   has two nexthops: REMAP cost=26, CAIDA cost=28.
   3. Trace daemon sends an Interest /trace/ndn/edu/ucla/app/<random3> and
   uses NextHopFaceId to direct this Interest to REMAP.
   4. Trace daemon on REMAP does the same as step2-3.
   5. Trace daemon on UCLA router receives step4 Interest from REMAP, and
   finds that /ndn/edu/ucla/app points to a local producer. Thus, it
   responds with a Data containing "spurs".
   6. Trace daemon on REMAP responds to step3 Interest with a Data
   containing "128.97.98.7,spurs".
   7. Trace daemon on Arizona responds to step1 Interest with a Data
   containing "hobo,128.97.98.7,spurs".
   8. Client displays the collected path from step7.

CCNx-Trace can only reveal the path indicates in FIB entry as lowest cost.
It does not necessarily reflect the path taken by actual application
Interests, because it does not take into consideration:

   - Forwarding strategy may send Interests towards a different nexthop.
   - ContentStore may satisfy an Interest, so that the Interest doesn't go
   all the way to producer machine.


Current NDN architecture does not support true traceroute. It requires
sending a normal application Interest, and collecting router identities
along the reverse path taken by Data or Nack. Revealing router identities
(including producer machine's identity) is in violation of NDN's privacy
benefits.

Yours, Junxiao

On Wed, Sep 7, 2016 at 10:23 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

> I am curious what the state-of-the-art is for tracing Interest/Data
> exchange?  If I want to see whether an Interest expressed by Consumer hits
> the Repo, is my only solution to watch the logs in NFD2 (or for anything
> potentially in the path, in a larger example), keep track of which face
> Repo corresponds to and see if things are forwarded?     Repo-ng doesn’t
> seem to say/log much itself.. but more generally the question here is about
> whether there are techniques to do Interest/Data packet tracing without
> manually- or custom- instrumenting each potential node in the path(s).
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160908/f84a5789/attachment.html>