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

From: Vern Paxson <[email-masked]>
Date: Sat, 27 Nov 1999 01:43:54 PST

> - (2.3) Why is RTTVAR computed before SRTT? Although, I don't have a 
> problem with that, the 4.4BSD code computes SRTT first. I assume there is 
> good reason but I think it should be written down.

While 4.4BSD computes SRTT first, it then computes RTTVAR based on the
*old* value of SRTT, so the effect is the same as the order given in
draft-paxson-tcp-rto-00.txt.

> - (2.4) Although I read the TSVWG minutes, I still wonder why there should 
> be a *fixed* RTO minimum of one second?

Well, as stated in the I-D:

          Traditionally, TCP implementations use coarse grain clocks to 
          measure the RTT and trigger the RTO, which imposes a large
          minimum value on the RTO.  Research suggests that a large
          minimum RTO is needed to keep TCP conservative and avoid
          spurious retransmissions [AP99].

So the 1 second minimum reflects that used by the traditional coarse-grained
timer.

Also, Van Jacobson (whom I've cc'd, in case he has anything to add) argued at
the meeting that the 1 second minimum is in fact not all that conservative:
you can get large RTT spikes even on LANs due to cross traffic.

		Vern

---

From: Reiner Ludwig <[email-masked]>
Date: Tue, 30 Nov 1999 10:55:45 +0100

>draft-paxson-tcp-rto-00.txt.

Yep, you're right.

>you can get large RTT spikes even on LANs due to cross traffic.

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.

An RTO-MIN of (2 * G) is necessary of course and has a good reason; at 
least for implementations that are based on a heartbeat timer. That RTO-MIN 
has the advantage that is adaptive to the OS's timer granularity.

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. The RTO might not be able to adapt fast enough in those 
situations. In that case, the R' in the RTO-MIN would help out.

///Reiner