[Nfd-dev] NDN Traceroute

[Davide Pesavento]

John,

the NIST paper has a "related work" section with references to all
previous work I know of.

Thanks,
Davide

On Fri, Oct 6, 2017 at 1:46 PM, Dehart, John <jdd at wustl.edu> wrote:
>
> Christos,
>
> I am in the process of gathering references/info for existing proposals,
> designs and implementations.
> Is this the CSU one you refer to:
>
> https://named-data.net/wp-content/uploads/2017/03/ndn-0055-2-trace.pdf
>
> I’m familiar with the NIST one described here:
>
> http://conferences.sigcomm.org/acm-icn/2017/proceedings/icn17-86.pdf
>
> If other folks could supply links to other designs or documents, that would
> be helpful.
>
> John
>
> On Oct 6, 2017, at 12:35 PM, Christos Papadopoulos <christos at colostate.edu>
> wrote:
>
> John,
>
> Before we get deeper into a discussion, have you looked at the existing
> implementations of NDNtrace? I know CSU has one that can be ported to NFD,
> and I thought NIST has another one.
>
> Could you use one of them?
>
> Christos.
>
>
>
> On 10/06/2017 09:38 AM, Dehart, John 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
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>