<div dir="ltr">We have used path-labels for measuring RTTs of network paths for optimising flow and congestion control since <div><br></div><div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px"><a href="https://scholar.google.com/scholar?oi=bibs&cluster=9676576925899360515&btnI=1&hl=fr" style="color:rgb(102,0,153);text-decoration-line:none">Multipath congestion control in content-centric networks</a></div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px">G Carofiglio, M Gallo, L Muscariello, M Papalini - … (INFOCOM NOMEN WKSHPS), 2013</div></div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px"><br></div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px">First implementation in ccnx-0.6 then ported to NFD years later and more recently we still use it  for CICN.</div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px">Implementations have improved over the years but the idea is the same.</div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px"><br></div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px">For RTC apps that's useful too, indeed.</div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px"><br></div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px">At this year ICN conference there is Ilya and Dave Oran's work that you should definitely look at.</div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px"><br></div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px">Luca</div><div style="margin:0px;padding:0px;border:0px;font-family:Arial,sans-serif;font-size:13px"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 6, 2017 at 5:38 PM, Dehart, John <span dir="ltr"><<a href="mailto:jdd@wustl.edu" target="_blank">jdd@wustl.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
All:<br>
<br>
After our recent discussions about ndn traceroute, I was tasked with<br>
describing my view of what an ndn traceroute capability would be like.<br>
I will try to find some time to review all the current and past traceroute<br>
designs, but for now, this email will serve to keep the conversation going.<br>
<br>
Keep in mind that I have not been involved in nfd development so<br>
I won’t be getting in to the details of what all this means for nfd code.<br>
Also, my terminology might not agree with the offical terminology.<br>
<br>
My immediate goal is to understand how interests are routed in the NDN<br>
Testbed at any given time. For example, I have a simple test that I have<br>
been running lately where I run 'ndnping /ndn/edu/ucla’ on the WU node<br>
and I see RTT’s bouncing around between 80ms and 1000ms<br>
and at times ndnping timeouts.<br>
<br>
For me, an ideal first step for an ndn traceroute capability would<br>
be to augment ndnping, ndnpingserver and nfd so that the ndnping interests<br>
would be augmented at each forwarder with a tag for that node. Then<br>
ndnpingserver could take those tags and return them in the data packet<br>
sent back to ndnping. ndnping could then report the RTT and the path.<br>
<br>
I understand that this would not test the possibility of finding application<br>
data in a Content Store along the path. But for me, that is fine. I’m not<br>
looking right now to test the intricate data flow of a multi-party application.<br>
Perhaps there is a better way to collect and return the path data to<br>
the source, something that would make it possible for a future version<br>
to include Content Store hits.<br>
<br>
I also believe that this will be an important tool for Jeff Burke’s group in the<br>
application testing they are trying to do. It may not be 100% of what they<br>
want and need, but I believe it will be a good start.<br>
<br>
In working with Jeff and Peter on ndnrtc testing, I came across my WU to<br>
UCLA ndnping test results.  Without an actual ndn-traceroute, I built my<br>
own with the capabilities I have as manager of the NDN Testbed. I set the<br>
US nodes up with nfd running in DEBUG, ran my ndnping test, collected<br>
nfd log files and wrote some scripts to parse them and find the path that<br>
my ndnpings were taking. Not exactly something that any user or app<br>
developer could do. I could only do it because I have privileged access<br>
to all the NDN Testbed nodes.<br>
<br>
John<br>
<br>
<br>
______________________________<wbr>_________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu">Nfd-dev@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/<wbr>mailman/listinfo/nfd-dev</a><br>
</blockquote></div><br></div>