Re: [tcpm] Tuning TCP parameters for the 21st century

Joe Touch <touch@ISI.EDU> Tue, 14 July 2009 14:16 UTC

Return-Path: <touch@ISI.EDU>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C07CE3A6EB7 for <>; Tue, 14 Jul 2009 07:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zTby7VGStqOF for <>; Tue, 14 Jul 2009 07:16:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CCD2B3A67A4 for <>; Tue, 14 Jul 2009 07:16:26 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id n6EEFbOM026131; Tue, 14 Jul 2009 07:15:39 -0700 (PDT)
Message-ID: <>
Date: Tue, 14 Jul 2009 07:15:37 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20090605)
MIME-Version: 1.0
To: Erik Nordmark <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: "" <>
Subject: Re: [tcpm] Tuning TCP parameters for the 21st century
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Jul 2009 14:16:27 -0000

Hash: SHA1

Erik Nordmark wrote:
> Jerry Chu wrote:
>> From our own measurement of world wide RTT distribution to Google servers
>> we believe 3secs is too conservative, and like to propose it to be
>> reduced
>> to 1sec.
>> Why does it matter?
>> We have seen SYN-ACK retransmission rates upto a few percentage points to
>> some of our servers. We also have indirect data showing the SYN (client
>> side) retransmission to be non-negligible (~1.42% worldwide). At a rate >
>> 1% a large RTO value can have a significant negative impact on the
>> average
>> end2end latency, hence the user experience. This is especially true for
>> short connections, including much of the web traffic.
> For short web traffic I'd assume many of the connections go to a server
> with which the client has recently had a tcp connection.
> What would be the pros and cons of using the cached rtt measurements
> from previous connections for the SYN

You can use more than cached RTT; the technique and some other cacheable
items are described in RFC2140.

The pro is more rapid convergence to an accurate RTT; the con is that
you're using a potentially invalid RTT, but then that's what you do when
you start without knowing the RTT at all anyway.

It has also been implemented in Linux; see RFC4614.

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -