<div dir="ltr"><div>Dear folks</div><div><br></div><div>This is a follow-up to <a href="http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-September/001992.html">http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-September/001992.html</a></div><div>I had a discussion with CCNx-Trace author about these limitations, and how NFD (formerly NDNFD) can allow a better traceroute tool. An excerpt of this conversion is pasted at the end of this message.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Yours, Junxiao</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 8, 2016 at 12:28 PM, Junxiao Shi <span dir="ltr"><<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.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 dir="ltr"><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></blockquote><div><br></div><div><br></div>---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Junxiao Shi</b> <span dir="ltr"><<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>></span><br>Date: Tue, Aug 27, 2013 at 11:11 PM<br>Subject: Re: CCNx Trace in NDNFD<br>To: Susmit <<a href="mailto:susmit@cs.colostate.edu">susmit@cs.colostate.edu</a>><br>Cc: Christos Papadopoulos <<a href="mailto:christos@cs.colostate.edu">christos@cs.colostate.edu</a>>, Beichuan Zhang <<a href="mailto:bzhang@cs.arizona.edu">bzhang@cs.arizona.edu</a>><br><br><div dir="ltr"><div>On Tue, Aug 27, 2013 at 9:15 AM, Susmit <span dir="ltr"><<a href="mailto:susmit@cs.colostate.edu" target="_blank">susmit@cs.colostate.edu</a>></span> wrote:<br></div></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div>> I'm looking at your CCNx Trace project. The report lists some design<br>> choices:<br>><br>> What is traceroute in CCN? Find all paths to all reachable producers.<br>> Which layer to implement? Application layer is possible, but strategy layer<br>> is better.<br>> Iterative or non-iterative? Non-iterative.<br>> Naming: /trace/prefix/random-number<br>> Node identifier: IP address<br>> Interest lifetime: default 4 seconds<br>><br>><br>> I'm writing an alternative NDN forwarding daemon, NDNFD, which is a<br>> replacement of ccnd. NDNFD has a strategy layer, and the strategy being used<br>> has a high impact on which producers are reachable. For example, a strategy<br>> designed to use in local-area networks may flood an Interest if there isn't<br>> a matching FIB entry, in an attempt to locate a nearby producer.<br><br></div>Are these strategies hard-coded? I think, a strategy layer which<br>parses simple firewall like rules would be more flexible.<br>Operators list the rules per user demand, ccnd parses those and set up<br>appropriate strategies.<br></blockquote><div><br></div><div>NDNFD forwarding strategies are coded in C++. "parsing firewall rules" gives the most flexibility, its performance is unsatisfactory without advanced techniques (such as dynamic code generation). Any rules must be loaded on program startup. In this sense, there is no difference whether strategies are coded in C++ or in a scripting language such as Lua.</div><div><br></div><div>Strategy is configured at namespace granularity. For example, /ndn/broadcast could use BcastStrategy to achieve true broadcast, while /ndn/<a href="http://ucla.edu/apps/lighting" target="_blank">ucla.edu/apps/lighting</a> could use SelfLearnStrategy to automatically find where the producer is.</div><div><a href="https://github.com/NDN-Routing/NDNFD/blob/master/docs/StrategyMgmt.md" target="_blank">NDNFD Strategy Management Protocol</a> allows operator/app to select a forwarding strategy on a namespace at runtime.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>> I'm especially interested in "best layer for traceroute". You mentioned CCNx<br>> Trace is implemented in application layer because ccnd does not have<br>> elaborate strategies in place. If you are to design a traceroute tool in a<br>> forwarding daemon that has different strategies (such as NDNFD), what design<br>> choices will you make? What features would you like to see added to the<br>> strategy layer and/or strategies so that traceroute would work better?<br><br></div>What we were looking for was flexibility. If I wanted to forward a<br>particular interest over a certain face, it should be easily<br>achievable.<br>So, an API for query CCND and get relevant information would be nice.<br>For example, given an interest name, find the outgoing face(s).<br>Also, updating the strategies used by ccnd should be easy.<br><br>Specifically for Trace, the following things would be useful:<br><br>a) Ability to specify forwarding face. If there are two routes for<br>/ndn/csu, I should be able to be forward an interest on both or one or<br>none.<br></blockquote><div><br></div><div>Depending on which strategy serves the namespace, actual face(s) being used may be different from what's in the FIB. Unfortunately, the decision of strategy can only be derived when it's given the Interest (not just a Name). A "dry run" (make decision without forwarding) is not always feasible, because some decisions depend on whether an upstream works.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">b) Flexible timeouts, I should be able to specify the interest<br>timeouts for intermediate nodes.<br></blockquote><div><br></div><div><div>traceroute as app: CCNx supports <a href="http://www.ccnx.org/releases/latest/doc/technical/InterestMessage.html" target="_blank"><FaceID></a> element in Interest.</div><div>traceroute in strategy layer: not a problem.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">c) Should be able to recognize a global namespace such as /trace or /ping<br></blockquote><div><br></div><div>traceroute as app: listen on this namespace, and pick a suitable strategy</div><div>traceroute in strategy layer: A global namespace is not necessary. Instead, an extensible command marker could be used. ccnx:/ndn/<a href="http://arizona.edu/yoursunny/vps5/web/%C1.edu.colostate.cs.trace/" target="_blank">arizona.edu/<wbr>yoursunny/vps5/web/%C1.edu.<wbr>colostate.cs.trace/</a></div></div></div></div></div></div></div></div>