IETF Logo Mail Archive

[tcpm] Tuning TCP parameters for the 21st century

Jerry Chu <hkchu@google.com> Mon, 13 July 2009 23:18 UTC

Return-Path: <hkchu@google.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 ED87B3A694D for <tcpm@core3.amsl.com>; Mon, 13 Jul 2009 16:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level:
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 I+8pFlFf7x6x for <tcpm@core3.amsl.com>; Mon, 13 Jul 2009 16:18:46 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id E579D3A6E76 for <tcpm@ietf.org>; Mon, 13 Jul 2009 16:18:40 -0700 (PDT)
Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id n6DNJ9nr027783 for <tcpm@ietf.org>; Tue, 14 Jul 2009 00:19:10 +0100
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247527150; bh=qW6Kb1npXCDNMUzWnOHF3slIp4c=; h=DomainKey-Signature:MIME-Version:Date:Message-ID:Subject:From:To: Content-Type:Content-Transfer-Encoding:X-System-Of-Record; b=qfYkd qrizQP3YYB8PCn34PTp3NHALq+95OPJ5WK8vn6PNTqn3Tz+WSKXHm0A1VLbSwZociv2 88/T6+4LRbDL2g==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type: content-transfer-encoding:x-system-of-record; b=sOpENdG1l01215g/4fyFpTXNlGg0oZrAPZ8IAPB5ATds1np8rVXrbWz3wyuo3l1lL L+Vh0c1qxl/Ybbizzszgg==
Received: from yxe27 (yxe27.prod.google.com [10.190.2.27]) by wpaz17.hot.corp.google.com with ESMTP id n6DNJ7r9019480 for <tcpm@ietf.org>; Mon, 13 Jul 2009 16:19:07 -0700
Received: by yxe27 with SMTP id 27so5871580yxe.0 for <tcpm@ietf.org>; Mon, 13 Jul 2009 16:19:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.34.3 with SMTP id h3mr7915053anh.137.1247527147119; Mon, 13 Jul 2009 16:19:07 -0700 (PDT)
Date: Mon, 13 Jul 2009 16:19:07 -0700
Message-ID: <d1c2719f0907131619t1a80997ep4080a3a721ef3627@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-System-Of-Record: true
Subject: [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: Mon, 13 Jul 2009 23:18:47 -0000

Sorry I don't have the I-D ready for submission yet (and the deadline
has passed anyway) so I'll try to describe what we are up to below.
I'll have more data to present in Stockholm.

At Google we have embarked on a mission to make the web faster, not
just for services provided by Google, but for every web user. We started
with TCP because TCP performance has always been a key component of
the end2end web performance. There are a number of default TCP parameter
settings, that, although conservative, have served us well over the
years. We believe the time has come to tune some of the parameters to
get more speed out of a much faster Internet than 10-20 years ago. The
current list includes:

Lowering initRTO
Increasing initcwnd
Lowering minRTO
Lowering delayed ack timer value

I'll start with Lowering initRTO.

RFC1122 contains the following paragraph:

The following values SHOULD be used to initialize the
estimation parameters for a new connection:

(a)  RTT = 0 seconds.

(b)  RTO = 3 seconds.  (The smoothed variance is to be
initialized to the value that will result in this RTO).

The "3secs SHOULD" is reaffirmed in RFC2988.

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

What's the downside?

For those users behind a slow (e.g., dialup, wireless) link, the RTT may
still go up to > 1 sec. We believe a small amount of supriously
retransmitted SYN/SYN-ACK packets should not be a cause for concern (e.g.,
inducing more congestion,...) In some rare case the TCP performance may be
negatively affected by false congestion backoff, resulted from dupacks
caused by multiple spuriously retransmitted SYN/SYN-ACK packets. We believe
there are techniques to detect and mitigate these cases.

I'd like to hear feedback from this list on the feasibility of reducing
initRTO. For some other items (e.g., increasing IW/RW...) unfortunately I
don't have data ready to share yet but if you have an opinion on them I'd
love to hear it too.

Thanks,

Jerry

On Mon, Jul 13, 2009 at 6:54 AM, Eddy, Wesley M. (GRC-MS00)[Verizon]
<wesley.m.eddy@nasa.gov> wrote:
>
> I've uploaded a draft TCPM agenda for IETF 75 at:
> http://www.ietf.org/proceedings/09jul/agenda/tcpm.txt
>
> I don't recall seeing an I-D or mail list thread for
> the topic Jerry Chu wants to discuss (lowering the
> initial RTO), so if he can give the mail list a bit
> of a description of his proposal that would be
> helpful.
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>

v2.23.0 | Report a Bug | By Email