[e2e] Estimating MS windows RTO equation

[Detlef Bosau]

Marco Mellia wrote:
> 
> We are actually discriminating between
> - needed retransmission due to RTO
> - unneeded retrasmission due to RTO (e.g., retransmitted packets already
> acked by the client).
> The second case may happen due to (but not only) spurious timeout
> expiration. What is interesting is that unneeded retransmission almost
> "disappear" if SACK is being used, hinting that they are more related to
> "wrong" selective retransmit behavior rathern then wrong RTO
> estimation...
> If you want, you can read that as "spurios rto firing" is a very rare
> event...
> 

>From what I understood so far, refer to e.g. RFC 3517, one of the main
objectives for the use
of SACK is loss detection. And there exist elaborate mechanisms for the
propper setting of the dupackthreshold used in actual
TCP implementations (as a replacement for the rather inflexible "3").

In addition, when we recall Edge´s paper, the central idea for the
constrution of an rxmit-Timer is to build an estimate  for
a RTT confidence interval. The basic idea behind this is Chebyshev´s
inequality, therefore the approach is as generic as it could be....

So, it would be extremely surprising, when some particular network´s
SRTO rate would exceed the accepted level, which is in fact
quite high. When I played around a bit with Edge´s formulae, I ended up
in an accptable SRTO rate of less then 1/5 for "E + 2*V"
and 1/17 for "E + 2*V". And this is about two orders of magnitude higher
than the values observed by Vacirca, Ziegler and Hasenleithner.

So, your observed behaviour, particularly the effect of a proper use of
SACK, exactly matches the expected behaviour.

Detlef
-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937