[Nfd-dev] NDN Traceroute

[Luca Muscariello]

We have used path-labels for measuring RTTs of network paths for optimising
flow and congestion control since

Multipath congestion control in content-centric networks
<https://scholar.google.com/scholar?oi=bibs&cluster=9676576925899360515&btnI=1&hl=fr>
G Carofiglio, M Gallo, L Muscariello, M Papalini - … (INFOCOM NOMEN
WKSHPS), 2013

First implementation in ccnx-0.6 then ported to NFD years later and more
recently we still use it  for CICN.
Implementations have improved over the years but the idea is the same.

For RTC apps that's useful too, indeed.

At this year ICN conference there is Ilya and Dave Oran's work that you
should definitely look at.

Luca


On Fri, Oct 6, 2017 at 5:38 PM, Dehart, John <jdd at wustl.edu> wrote:

>
> All:
>
> After our recent discussions about ndn traceroute, I was tasked with
> describing my view of what an ndn traceroute capability would be like.
> I will try to find some time to review all the current and past traceroute
> designs, but for now, this email will serve to keep the conversation going.
>
> Keep in mind that I have not been involved in nfd development so
> I won’t be getting in to the details of what all this means for nfd code.
> Also, my terminology might not agree with the offical terminology.
>
> My immediate goal is to understand how interests are routed in the NDN
> Testbed at any given time. For example, I have a simple test that I have
> been running lately where I run 'ndnping /ndn/edu/ucla’ on the WU node
> and I see RTT’s bouncing around between 80ms and 1000ms
> and at times ndnping timeouts.
>
> For me, an ideal first step for an ndn traceroute capability would
> be to augment ndnping, ndnpingserver and nfd so that the ndnping interests
> would be augmented at each forwarder with a tag for that node. Then
> ndnpingserver could take those tags and return them in the data packet
> sent back to ndnping. ndnping could then report the RTT and the path.
>
> I understand that this would not test the possibility of finding
> application
> data in a Content Store along the path. But for me, that is fine. I’m not
> looking right now to test the intricate data flow of a multi-party
> application.
> Perhaps there is a better way to collect and return the path data to
> the source, something that would make it possible for a future version
> to include Content Store hits.
>
> I also believe that this will be an important tool for Jeff Burke’s group
> in the
> application testing they are trying to do. It may not be 100% of what they
> want and need, but I believe it will be a good start.
>
> In working with Jeff and Peter on ndnrtc testing, I came across my WU to
> UCLA ndnping test results.  Without an actual ndn-traceroute, I built my
> own with the capabilities I have as manager of the NDN Testbed. I set the
> US nodes up with nfd running in DEBUG, ran my ndnping test, collected
> nfd log files and wrote some scripts to parse them and find the path that
> my ndnpings were taking. Not exactly something that any user or app
> developer could do. I could only do it because I have privileged access
> to all the NDN Testbed nodes.
>
> John
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20171006/ee7c5c36/attachment.html>