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

Reiner Ludwig <Reiner.Ludwig@eed.ericsson.se> Tue, 30 November 1999 09:59 UTC

Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18271 for <tsvwg@ietf.org>; Tue, 30 Nov 1999 04:59:31 -0500 (EST)
Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.130.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id KAA26930; Tue, 30 Nov 1999 10:59:16 +0100 (MET)
Received: from eifel.eed.ericsson.se (ki-80.kiedt.ericsson.se [147.214.100.80]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id KAA13495; Tue, 30 Nov 1999 10:59:09 +0100 (MET)
Message-Id: <4.2.0.58.19991130073037.009f6d90@chapelle.ericsson.se>
X-Sender: eedrel@chapelle.ericsson.se
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 30 Nov 1999 10:55:45 +0100
To: Vern Paxson <vern@ee.lbl.gov>
From: Reiner Ludwig <Reiner.Ludwig@eed.ericsson.se>
Subject: Re: [Tsvwg] Input for draft-paxson-tcp-rto-00.txt
Cc: Reiner Ludwig <Reiner.Ludwig@eed.ericsson.se>, Scott Bradner <sob@harvard.edu>, tsvwg@ietf.org, van@cisco.com
In-Reply-To: <199911270943.BAA24610@daffy.ee.lbl.gov>
References: <Your message of Fri, 26 Nov 1999 06:13:31 PST.>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"

At 10:43 27.11.99 , Vern Paxson wrote:
> > - (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.

Yep, you're right.

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

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