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

Jerry Chu <hkchu@google.com> Tue, 14 July 2009 22:06 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 50F553A6D03 for <tcpm@core3.amsl.com>; Tue, 14 Jul 2009 15:06:22 -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 FYFw41OKYCDH for <tcpm@core3.amsl.com>; Tue, 14 Jul 2009 15:06:21 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 42A783A6F1C for <tcpm@ietf.org>; Tue, 14 Jul 2009 15:05:41 -0700 (PDT)
Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id n6EJfj4t002598 for <tcpm@ietf.org>; Tue, 14 Jul 2009 12:41:45 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1247600505; bh=Q4Q1pmXoaZYxnOkNMnSf3nxFdUI=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=CmIrfLLp3a20HWfF3N OIwVasYdOwRpK445l1/po8KxY8afw3pC74yTz+fB8FW+5jpqA+jjV5DRi1QzZAaf1sF w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Fqk2nRHkS79X9Jw9MTfE3oOjYMmn1OIQenNbQTBQ88eXbrnpC87pn9VCO9jsDhadh EjHeCAb1WL9HC23Ni/OZQ==
Received: from an-out-0708.google.com (ancc37.prod.google.com [10.100.29.37]) by zps77.corp.google.com with ESMTP id n6EJfcMR028879 for <tcpm@ietf.org>; Tue, 14 Jul 2009 12:41:43 -0700
Received: by an-out-0708.google.com with SMTP id c37so1737909anc.43 for <tcpm@ietf.org>; Tue, 14 Jul 2009 12:41:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.152.12 with SMTP id z12mr9016612and.96.1247600502804; Tue, 14 Jul 2009 12:41:42 -0700 (PDT)
In-Reply-To: <4A5C9309.8030704@isi.edu>
References: <d1c2719f0907131619t1a80997ep4080a3a721ef3627@mail.gmail.com> <4A5C540E.9070104@sun.com> <4A5C9309.8030704@isi.edu>
Date: Tue, 14 Jul 2009 12:41:42 -0700
Message-ID: <d1c2719f0907141241p73e605adqc1d2e6f0db4eb3aa@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-System-Of-Record: true
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 22:06:22 -0000

On Tue, Jul 14, 2009 at 7:15 AM, Joe Touch<touch@isi.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.

Yes we are very aware of your proposal. I think the most effective one to speed
up short connections is the snd_cwnd reuse, but unfortunately it's also the most
dicey due to cwnd's highly temporal nature. Is this why snd_cwnd reuse was not
implemented per rfc2140? Any insight and suggestion will be much appreciated.

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

Yes Linux stack maintains a "destination cache" of ssthresh and RTT on
a per dest IP address basis. It doesn't currently use snd_cwnd, probably
out of the same concerned mentioned above? Also it is very conservative
hence won't use the cached RTT value unless the timestamp option is
on.

Also the dst cache is only consulted after 3WHS. So for SYN/SYN-ACK
the initRTO is still set to 3secs (don't know why).

Jerry

>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpckwkACgkQE5f5cImnZruYrQCgkCe/wm7W4F78Iy9K5gEcMtj5
> xekAoMbbvAXZA230zsKCxsdy3toZA+1N
> =o0dt
> -----END PGP SIGNATURE-----
>