[e2e] An alternative algorithm of calculating RTO
huitema at windows.microsoft.com
Mon Jun 3 15:51:57 PDT 2002
> >If implemented all with integer operation and run on a modern
> >high-frequency CPU with level-1 cache, the overhead of calculating
> >and crttvar my be trival.
> I don't think the overhead really is as insignificant as you
> suggest. Network speeds are increasing much faster than CPU speeds,
> even if the cost is trivial now it won't necessarily remain trivial.
In fact, if we were to change the TCP RTT algorithm, we should try to
address the biggest problem the current algorithm is not solving, i.e.
its inadequacy if the delay distribution is heavy tailed. In a heavy
tail distribution, there is a significant possibility to observe a "very
long" sample; if the only filtering in effect is exponential smoothing,
then this aberrant sample is going to remain in the averaged results for
a very long time. The running average procedure that is being proposed
is not significantly better in that respect -- the spike would remain in
effect for 8 to 32 RTT.
-- Christian Huitema
More information about the end2end-interest