Re: [tcpm] TCP tuning

Jerry Chu <hkchu@google.com> Wed, 03 February 2010 20:44 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 7AA3A3A683B for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 12:44:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.777
X-Spam-Level:
X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 IEY2aa-ycfd1 for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 12:44:17 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CC5F328C0CF for <tcpm@ietf.org>; Wed, 3 Feb 2010 12:43:21 -0800 (PST)
Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o13Ki4lu002101 for <tcpm@ietf.org>; Wed, 3 Feb 2010 12:44:04 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265229844; bh=g/kN5iVCmDmwZ6ZVpUiP/vKETYM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=oRRUbTziekNyl6EL0LzScyr+xgTx+mxdqTctiGzCXoaJj/krlgIMknapHTBztVZFK QKkDwndS3+Skzy3AOuTzA==
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=NRBU+X7B4Wde+jrmFstN4H8E9K5WTH/628w3/mYHLkRgkdFSZkL/3HyyqdLsMeRgu XdDEYrFfSbJ9jAmF9ktqw==
Received: from pxi42 (pxi42.prod.google.com [10.243.27.42]) by wpaz24.hot.corp.google.com with ESMTP id o13Ki36P027305 for <tcpm@ietf.org>; Wed, 3 Feb 2010 12:44:03 -0800
Received: by pxi42 with SMTP id 42so2839641pxi.5 for <tcpm@ietf.org>; Wed, 03 Feb 2010 12:44:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.141.12.3 with SMTP id p3mr73847rvi.194.1265229842635; Wed, 03 Feb 2010 12:44:02 -0800 (PST)
In-Reply-To: <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com>
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com>
Date: Wed, 03 Feb 2010 12:44:02 -0800
Message-ID: <d1c2719f1002031244g3415c8e1r7d36e26058158d20@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: John Heffner <johnwheffner@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: "tcpm@ietf.org WG" <tcpm@ietf.org>
Subject: Re: [tcpm] TCP tuning
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: Wed, 03 Feb 2010 20:44:18 -0000

Hi John,

On Wed, Feb 3, 2010 at 12:32 PM, John Heffner <johnwheffner@gmail.com> wrote:
> I would like to see tcpm take on the initial window issue, though as
> Joe notes we probably do not yet know enough to formally take this on
> as a charter item.  (Or, would this be a tsvwg item due to possible
> wider impact?)
>
> A couple thoughts:
> - A large initial window should probably only be used by mutual
> agreement.  Maybe via a TCP option during the handshake?

This may not be needed. A receiver can effectively constrain the
sender's window by advertising a smaller initial receive window.

Obviously this works for only the initial window, not the restart window.
(Oh, on a second thought this can be made to work for the restart
window too.)

> - A significant increase to the initial window might benefit from
> introduction of some form of pacing, since you won't have any ack
> clock yet.  This might help reduce losses and delay jitter.

Agreed. The question is, what is that threshold of window/burst size
beyond which pacing is required. My current guess is > 10.

Jerry

>
>  -John
>
>
>
> On Wed, Feb 3, 2010 at 9:28 AM, Lars Eggert <lars.eggert@nokia.com> wrote:
>> Hi,
>>
>> Jerry Chu has recently started the discussion on whether we need to think about tweaking TCP for the "modern Internet." Just came across another presentation from (AFAICT) another corner of Google that makes similar arguments.
>>
>> FYI: http://sites.google.com/a/chromium.org/dev/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf
>>
>> This topic seems to be gaining momentum, and the WG should take some time considering if there is work here for it.
>>
>> Lars
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>