[e2e] How could I know one RTT estimation techniques better thanthe other?

[Rik Wade]

Craig Partridge wrote:

>I'm not sure I agree however, with your metrics.  In the late 80s and
>early 90s, there was a lot of discussion about how fast the RTT
>estimator should react, and as I recall the discussion, the key
>requirements were that the RTT estimator should be fairly robust
>against short-term transients (esp. conditions that typically varied
>over an RTT -- such as queue length) and also be aggressive about
>accepting bad news (longer RTTs), while conservative about accepting
>good news (shorter RTTs)
>  
>
I did quite a bit of work with RTT and throughput estimation for 
transport protocols as part of my PhD. I was mainly looking at ways and 
means of pro-actively avoiding congestion, so began by looking at the 
work done in TCP Vegas and others. My final estimator implementation was 
somewhat simplified and looked solely at variation in RTT rather than 
computing throughput estimations. I found this to work well, at least in 
a simulation environment (ns-2). My protocol used variation in RTT to 
adjust the flow of tokens in to a token bucket, replacing the 
traditional congestion window and providing a bit more flexibility in 
terms of burstabiltiy and shaping.

I would second the issue that Craig mentions above. The tuning of this 
component is down to the speed at which it reacts to these values. I did 
most of my work in simulation, but I would definitely recommend 
supporting it with practical experiments on a live network. I, for one, 
found simulation to be a bit too clinical to get a feel for how a "real" 
protocol should react to these RTT figures. One of my items of future 
work was to consider how a protocol may be "self-tuning" in this sense 
because one thing I learned was that hard-wired values in protocols can 
be a Bad Thing and certainly don't transfer well from a simulated to 
live environment. This could, however, just be down to my skill with 
ns-2 ;-)
--
Rik Wade