<div dir="ltr">Hi Jeff<div><br></div><div>As Davide has already answered, <a href="https://github.com/named-data/ndn-tools/tree/master/tools/dump" target="_blank">ndndump</a> and <a href="https://github.com/named-data/ndn-tools/tree/master/tools/dissect-wireshark">NDN packet dissector for Wireshark</a> are the best available tools.</div><div>If an application lacks logging capability (repo-ng in your example), there are two techniques to observe packets to and from this application:</div><div><ul><li>Force the application to connect to NFD over TCP. In ndn-cxx, you can set environ <font face="monospace, monospace">NDN_CLIENT_TRANSPORT=tcp4://<a href="http://127.0.0.1:6363">127.0.0.1:6363</a></font> to change the default to TCP. Then, you can use ndndump or Wireshark to capture packets on the loopback interface.</li><li>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. <a href="http://linux.die.net/man/1/socat">socat</a> can be used as the proxy. The traffic log can then be analyzed with <a href="https://github.com/named-data/ndn-tools/tree/master/tools/dissect">ndn-dissect</a>.</li></ul></div><div><br></div><div><a href="https://named-data.net/codebase/applications/ccnx-trace/">CCNx-Trace</a> 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.</div><div><br></div><div>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)</div><div><ol><li>Client expresses an Interest <font face="monospace, monospace">/trace/ndn/edu/ucla/app/<random1></font>.</li><li>Trace daemon on Arizona (listening on <font face="monospace, monospace">/trace</font>) receives this Interest, requests the FIB dataset, and finds that a longest prefix match for <font face="monospace, monospace">/ndn/edu/ucla/app</font> would match FIB entry <font face="monospace, monospace">/ndn/edu/ucla</font>. This FIB entry has two nexthops: REMAP cost=26, CAIDA cost=28.</li><li>Trace daemon sends an Interest <span style="font-family:monospace,monospace">/trace/ndn/edu/ucla/app/<random3></span> and uses NextHopFaceId to direct this Interest to REMAP.</li><li>Trace daemon on REMAP does the same as step2-3.</li><li>Trace daemon on UCLA router receives step4 Interest from REMAP, and finds that <span style="font-family:monospace,monospace">/ndn/edu/ucla/app</span> points to a local producer. Thus, it responds with a Data containing "spurs".</li><li>Trace daemon on REMAP responds to step3 Interest with a Data containing "128.97.98.7,spurs".</li><li>Trace daemon on Arizona responds to step1 Interest with a Data containing "hobo,128.97.98.7,spurs".</li><li>Client displays the collected path from step7.</li></ol></div><div>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:</div><div><ul><li>Forwarding strategy may send Interests towards a different nexthop.</li><li>ContentStore may satisfy an Interest, so that the Interest doesn't go all the way to producer machine.</li></ul></div><div><br></div><div>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.</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 7, 2016 at 10:23 PM, Burke, Jeff <span dir="ltr"><<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">







<div bgcolor="white" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11pt">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).   </span><br></p>
<p class="MsoNormal"><br></p></div></div></blockquote></div></div></div></div>