[Nfd-dev] RTT estimator

Lan Wang (lanwang) lanwang at memphis.edu
Fri May 15 13:20:33 PDT 2015


I see.  We'll create a new RttEstimator based on TCP's algorithm.

Lan

On May 15, 2015, at 1:23 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
 wrote:


Hi Lan

NFD RttEstimator code is copied from NDNFD. This code is written according to ns3::RttMeanDeviation.
I don't have particular reason for those differences from RFC6298.

Recent strategy design suggests that each strategy may need a different RttEstimator.
Therefore, your strategy could duplicate RttEstimator and give it a different name or make it a nested class, and then make changes.

Yours, Junxiao

On May 15, 2015 09:39, "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Hi Junxiao,

We're implementing a forwarding strategy and using the RTT estimator you have in NFD.   While debugging some results, we looked at the RTO values computed by the RTT estimator.   It seems that the RTT estimator in NFD has several features that are different from the TCP retransmission timeout algorithm (https://tools.ietf.org/html/rfc6298).

1. you use the same multiplier (0.1) for SRTT and RTTVAR.  But in TCP, it's 0.125 for SRTT and 0.25 for RTTVAR.

2. you initialize the RTTVAR to be the same as the first RTT measurement.  But in TCP, it's initialized to 1/2 of the first RTT measurement.

I'm wondering why you made the above decisions.   Thanks.

Lan


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


More information about the Nfd-dev mailing list