[Nfd-dev] traceroute with NFD

[Junxiao Shi]

Dear folks

This is a follow-up to
http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-September/001992.html
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.

Yours, Junxiao

On Thu, Sep 8, 2016 at 12:28 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> 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.
>
>

---------- Forwarded message ----------
From: Junxiao Shi <shijunxiao at email.arizona.edu>
Date: Tue, Aug 27, 2013 at 11:11 PM
Subject: Re: CCNx Trace in NDNFD
To: Susmit <susmit at cs.colostate.edu>
Cc: Christos Papadopoulos <christos at cs.colostate.edu>, Beichuan Zhang <
bzhang at cs.arizona.edu>

On Tue, Aug 27, 2013 at 9:15 AM, Susmit <susmit at cs.colostate.edu> wrote:

>
> > I'm looking at your CCNx Trace project. The report lists some design
> > choices:
> >
> > What is traceroute in CCN? Find all paths to all reachable producers.
> > Which layer to implement? Application layer is possible, but strategy
> layer
> > is better.
> > Iterative or non-iterative? Non-iterative.
> > Naming: /trace/prefix/random-number
> > Node identifier: IP address
> > Interest lifetime: default 4 seconds
> >
> >
> > I'm writing an alternative NDN forwarding daemon, NDNFD, which is a
> > replacement of ccnd. NDNFD has a strategy layer, and the strategy being
> used
> > has a high impact on which producers are reachable. For example, a
> strategy
> > designed to use in local-area networks may flood an Interest if there
> isn't
> > a matching FIB entry, in an attempt to locate a nearby producer.
>
> Are these strategies hard-coded? I think, a strategy layer which
> parses simple firewall like rules would be more flexible.
> Operators list the rules per user demand, ccnd parses those and set up
> appropriate strategies.
>

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.

Strategy is configured at namespace granularity. For example,
/ndn/broadcast could use BcastStrategy to achieve true broadcast, while
/ndn/ucla.edu/apps/lighting could use SelfLearnStrategy to automatically
find where the producer is.
NDNFD Strategy Management Protocol
<https://github.com/NDN-Routing/NDNFD/blob/master/docs/StrategyMgmt.md> allows
operator/app to select a forwarding strategy on a namespace at runtime.


>
> > I'm especially interested in "best layer for traceroute". You mentioned
> CCNx
> > Trace is implemented in application layer because ccnd does not have
> > elaborate strategies in place. If you are to design a traceroute tool in
> a
> > forwarding daemon that has different strategies (such as NDNFD), what
> design
> > choices will you make? What features would you like to see added to the
> > strategy layer and/or strategies so that traceroute would work better?
>
> What we were looking for was flexibility. If I wanted to forward a
> particular interest over a certain face, it should be easily
> achievable.
> So, an API for query CCND and get relevant information would be nice.
> For example, given an interest name, find the outgoing face(s).
> Also, updating the strategies used by ccnd should be easy.
>
> Specifically for Trace, the following things would be useful:
>
> a) Ability to specify forwarding face. If there are two routes for
> /ndn/csu, I should be able to be forward an interest on both or one or
> none.
>

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.


> b) Flexible timeouts, I should be able to specify the interest
> timeouts for intermediate nodes.
>

traceroute as app: CCNx supports <FaceID>
<http://www.ccnx.org/releases/latest/doc/technical/InterestMessage.html>
element
in Interest.
traceroute in strategy layer: not a problem.


> c) Should be able to recognize a global namespace such as /trace or /ping
>

traceroute as app: listen on this namespace, and pick a suitable strategy
traceroute in strategy layer: A global namespace is not necessary. Instead,
an extensible command marker could be used. ccnx:/ndn/arizona.edu/
yoursunny/vps5/web/%C1.edu.colostate.cs.trace/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160927/73de8ab2/attachment.html>