Re: [Tsvwg] Input for draft-paxson-tcp-rto-00.txt

[Reiner Ludwig <[e-mail]>]

At 10:46 01.12.99 , Vern Paxson wrote:
> > Even if you get those RTT spikes, this does not argue in favor of a magic
> > number, like 1 second, for an RTO-MIN. It might argue in favor of an RTO
> > that keeps a longer history of the past.
>
>Again, the number is magic because it's widespread existing practice and
>known to be conservative.  The "RTO that keeps a longer history of the
>past" is certainly a possiblity for **future** development of the RTO
>algorithm, but that is not the scope of this document.

I understand that.

But you said that draft-paxson-tcp-rto-00.txt is supposed to document the 
"de facto". The de facto implementations use an RTO-MIN of (2 * G) and not 
1 second. In addition, we know that there are widespread operating systems 
that have a timer granularity < 500 ms.

> > The issue of RTT spikes or situations where the RTT suddenly increases and
> > stays at that level is exactly why I believe that the RTO-MIN should be
> > defined as (R' + 2 * G), where R' is the latest RTT measurement, as 
> done in
> > FreeBSD.
>
>Where are you getting this?  FreeBSD doesn't have a R' factor, unless
>you're counting the restarting of the timer as new acks come in, which is
>already in the description of the algorithm in the I-D.  And G = 500 msec
>in the FreeBSD distribution.

FreeBSD 3.2 in tcp_input.c at the end of tcp_xmit_timer():

TCPT_RANGESET(tp->t_rxtcur,
               TCP_REXMTVAL(tp),
               max(tp->t_rttmin, rtt + 2),
               TCPTV_REXMTMAX);

which actually is (R' + 3 * G) because rtt includes an extra tick, i.e., 
RTT = (rtt - 1).

///Reiner