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

Vern Paxson <vern@ee.lbl.gov> Sat, 27 November 1999 09:44 UTC

Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07949 for <tsvwg@ietf.org>; Sat, 27 Nov 1999 04:44:15 -0500 (EST)
Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id BAA24610; Sat, 27 Nov 1999 01:43:54 -0800 (PST)
Message-Id: <199911270943.BAA24610@daffy.ee.lbl.gov>
To: Reiner Ludwig <Reiner.Ludwig@eed.ericsson.se>
Cc: Scott Bradner <sob@harvard.edu>, tsvwg@ietf.org, van@cisco.com
Subject: Re: [Tsvwg] Input for draft-paxson-tcp-rto-00.txt
In-reply-to: Your message of Fri, 26 Nov 1999 06:13:31 PST.
Date: Sat, 27 Nov 1999 01:43:54 -0800
From: Vern Paxson <vern@ee.lbl.gov>

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