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

[Vince Lehman (vslehman)]

Hi Junxiao,

A registration for a new UDP face causes the RTT to increase slightly, ~2ms above the previous experiment:

Content From /ndn - Ping Reference = 477477776   - Round Trip Time = 0.778 ms
Content From /ndn - Ping Reference = 477477777   - Round Trip Time = 0.649 ms
Content From /ndn - Ping Reference = 477477778   - Round Trip Time = 16.614 ms
Content From /ndn - Ping Reference = 477477779   - Round Trip Time = 0.982 ms

A registration for a non-existent face ID causes a large increase in the RTT:

Content From /ndn - Ping Reference = 479746716   - Round Trip Time = 0.77 ms
Content From /ndn - Ping Reference = 479746717   - Round Trip Time = 0.695 ms
Content From /ndn - Ping Reference = 479746718   - Round Trip Time = 52.996 ms
Content From /ndn - Ping Reference = 479746719   - Round Trip Time = 0.808 ms

Since we simply want to update the expiration time for a particular namespace in the RIB, would there be any use for a protocol extension that allows for the expiration time for a namespace to be updated with one RIB command?
--
Vince Lehman

On Apr 24, 2015, at 1:38 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Lan

Before I can suggest any code patches, additional experiment is needed to confirm or reject the hypothesis in http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-April/001049.html .

If you want to measure RTT changes due to route changes, one possible way is to increase the link delay.
When the link delay is 10ms, a 10ms RTT change is 50% and appears significant.
When the link delay is 500ms, a 10ms RTT change is 1% and appears negligible.

Yours, Junxiao

On Fri, Apr 24, 2015 at 11:33 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
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


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