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

From: Vern Paxson <[email-masked]>
Date: Wed, 01 Dec 1999 01:46:22 PST

> 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.

> 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.

		Vern

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 01 Dec 1999 12:17:27 +0100

>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.

>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

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 1 Dec 1999 10:18:03 -0800 (PST)

> that have a timer granularity < 500 ms.

Another minor constraint with respect to RTO-MIN if RTO-MIN is smaller than
1 s. RTO-MIN has to be greater than the delay ack timeout to avoid false
retransmission.  This means RTO-MIN has to be greater than 500 ms, which is
the maximum delay ack timeout allows by TCP standard.

							K. Poon.
							[email-masked]