[Nfd-dev] RTT delay caused by RIB registration commands

Lan Wang (lanwang) lanwang at memphis.edu
Fri Apr 24 11:33:52 PDT 2015


Basically, we saw a large jump in ndnping results between two nodes even though there was no path change for the path between those two nodes.  We found that it was because those nodes (or the intermediate ones) were busy updating their FIB (for other routes) -- each registration and unregistration of a route obviously took ~10ms for NRD/NFD to process.

We were interested in RTT changes due to route changes, so the extra delay caused by the route registrations is an undesirable side effect we'd like to remove (thus Vince's email).  So any suggestions on how to deal with this in our experiments are highly appreciated.

In the long term, we do need to address the problem of high processing delays of route registrations.

Lan

On Apr 23, 2015, at 6:15 PM, Vince Lehman (vslehman) <vslehman at memphis.edu<mailto:vslehman at memphis.edu>> wrote:

Hi all,

I was looking over some of our hyperbolic routing results and noticed some substantial delays in ndnping when RIB registration commands are sent to the forwarder.

Our tests use ndnping to track the RTTs between routers and when a node fails, the routing converges and new routes are registered with NFD.
What I saw in the logs was that even with our link-state routing implementation, two nodes that are directly connected were experiencing additional delay even though
their direct path was unaffected by the failed node.

I am able to replicate this result on my laptop from the command line. When I run an ndnping server and ndnping on my laptop, I see consistent RTTs. But, when I send
nfdc register commands at a relatively slow interval (0.5 s) at the same time, I see a large jump in the RTT.

Below is an example. I started the RIB registrations right after the ping with reference 810245465.

Content From /ndn - Ping Reference = 810245457   - Round Trip Time = 1.307 ms
Content From /ndn - Ping Reference = 810245458   - Round Trip Time = 1.296 ms
Content From /ndn - Ping Reference = 810245459   - Round Trip Time = 1.229 ms
Content From /ndn - Ping Reference = 810245460   - Round Trip Time = 1.291 ms
Content From /ndn - Ping Reference = 810245461   - Round Trip Time = 1.155 ms
Content From /ndn - Ping Reference = 810245462   - Round Trip Time = 1.251 ms
Content From /ndn - Ping Reference = 810245463   - Round Trip Time = 1.271 ms
Content From /ndn - Ping Reference = 810245464   - Round Trip Time = 1.436 ms
Content From /ndn - Ping Reference = 810245465   - Round Trip Time = 1.328 ms
Content From /ndn - Ping Reference = 810245466   - Round Trip Time = 1.22 ms
Content From /ndn - Ping Reference = 810245467   - Round Trip Time = 14.618 ms
Content From /ndn - Ping Reference = 810245468   - Round Trip Time = 1.255 ms
Content From /ndn - Ping Reference = 810245469   - Round Trip Time = 1.211 ms
Content From /ndn - Ping Reference = 810245470   - Round Trip Time = 0.854 ms
Content From /ndn - Ping Reference = 810245471   - Round Trip Time = 1.274 ms

I used this simple bash script to send the registration commands:
for i in `seq 1 25`; do
  nfdc register /a 258
  sleep 0.5
done

Has anyone else experienced this delay caused by registration commands? Any ideas to help reduce the RTT variance to stabilize our results?

Any comments or suggestions you can provide would be appreciated. Thanks.

--
Vince Lehman


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150424/a8331073/attachment.html>


More information about the Nfd-dev mailing list