IETF Logo Mail Archive

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

Erik Nordmark <erik.nordmark@sun.com> Tue, 14 July 2009 09:46 UTC

Return-Path: <erik.nordmark@sun.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACEA43A6EA1 for <tcpm@core3.amsl.com>; Tue, 14 Jul 2009 02:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.419
X-Spam-Level:
X-Spam-Status: No, score=-5.419 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4je4Ln2Wc7t for <tcpm@core3.amsl.com>; Tue, 14 Jul 2009 02:46:58 -0700 (PDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id D49B23A6E5A for <tcpm@ietf.org>; Tue, 14 Jul 2009 02:46:57 -0700 (PDT)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6E9kwso000817; Tue, 14 Jul 2009 09:46:58 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n6E9kt9Q360004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jul 2009 02:46:57 -0700 (PDT)
Message-ID: <4A5C540E.9070104@sun.com>
Date: Tue, 14 Jul 2009 11:46:54 +0200
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090323)
MIME-Version: 1.0
To: Jerry Chu <hkchu@google.com>
References: <d1c2719f0907131619t1a80997ep4080a3a721ef3627@mail.gmail.com>
In-Reply-To: <d1c2719f0907131619t1a80997ep4080a3a721ef3627@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] Tuning TCP parameters for the 21st century
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2009 09:46:58 -0000

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?

    Erik

v2.31.3 | Report a Bug | By Email | System Status