Re: [tcpm] TCP tuning

Jerry Chu <hkchu@google.com> Wed, 03 February 2010 21:38 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 BBD0C3A69C5 for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 13:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.548
X-Spam-Level:
X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=-0.571, 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 q9t3yHiEOCgP for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 13:38:41 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D48CB3A6996 for <tcpm@ietf.org>; Wed, 3 Feb 2010 13:38:40 -0800 (PST)
Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id o13LdNTY031077 for <tcpm@ietf.org>; Wed, 3 Feb 2010 13:39:23 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265233164; bh=vkYZqZnBhkHqHPM7QGEyJVPFTPU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=gFDGRRiFXS1WHJe9TQUkWW5YXMIR7lwenOK8QVpbqfcMwazjdx6XSBKF4XKMP/yxu AUFIDZ8v5S4QY5maAh9xw==
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:x-system-of-record; b=VYh/JOlYqMJGzgmq9w0M4E55aTv4hbzQ28A63TB3bkDCUmcEtTcq3Mvgn96pzoPIr avlbgRckIxPSXEepwKblQ==
Received: from pzk14 (pzk14.prod.google.com [10.243.19.142]) by spaceape10.eur.corp.google.com with ESMTP id o13LcBt7004718 for <tcpm@ietf.org>; Wed, 3 Feb 2010 13:39:22 -0800
Received: by pzk14 with SMTP id 14so526764pzk.3 for <tcpm@ietf.org>; Wed, 03 Feb 2010 13:39:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.179.20 with SMTP id b20mr142531rvf.47.1265233161568; Wed, 03 Feb 2010 13:39:21 -0800 (PST)
In-Reply-To: <4B69CDD7.6060802@isi.edu>
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <d1c2719f1002031110v3b76ca9eu14c9a110847548e7@mail.gmail.com> <4B69CDD7.6060802@isi.edu>
Date: Wed, 03 Feb 2010 13:39:21 -0800
Message-ID: <d1c2719f1002031339u14709270k6452c05f0dd3c39e@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Cc: tcpm@ietf.org, "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
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 21:38:41 -0000

On Wed, Feb 3, 2010 at 11:26 AM, Joe Touch <touch@isi.edu> wrote:
>
>
> Jerry Chu wrote:
>> On Wed, Feb 3, 2010 at 7:17 AM, SCHARF, Michael
>> <Michael.Scharf@alcatel-lucent.com> wrote:
>>>> This topic seems to be gaining momentum, and the WG should
>>>> take some time considering if there is work here for it.
>>> IMHO there could indeed be room for increasing the initial window. If
>>> most data transfers continue to be smaller than 3 MSS, a larger initial
>>> window would not necessarily cause harm, as it is seldomly used. Still,
>>> this would speed up those data transfers that currently suffer from
>>> Slow-Start.
>>
>> Actually our data points to the contrary - the average web object and page
>> size have been rising steadily. E.g., the majority of our search responses
>> no longer fit in 3 MSS these days.
>
> This should be relevant only for the first response from a given IP
> address; persistent connections should render this moot for subsequent
> requests.

Yes we are well aware of the advantage of maintaining persistent connections.
In fact this is one of the reasons holding us back from resurrecting T/TCP
(in addition to other security issues).

But from our own observation the average HTTP connections just don't
persistent that long for some reason. I don't remember the data or all
the technical reasons on top of my head, but can surely try to get them for
you.

There are other limitations of HTTP 1/1:

1. obviously its effectiveness depends on user's web surfing pattern.
2. web browsers have been going down the slope of opening more and
more simultaneous connections anyway, partly to circumvent HTTP's
serialization, an issue SPDY tries to address.
3. practically web servers have only limited resources. can't hold too many
open connections.
4. a web object will make the TCP slow start algorithm to grow its cwnd
only upto the size of the object. As such, even with persistent connections,
a web object that is larger than any of its predecessors will hit the window
limit, and take more than one round trip time to complete. So persistent
connections might not be as effective as one might think.

>
> Again, the question arises as to how much this is going to achieve a
> noticeable impact.

Quite significant in our study. Will present our result at IETF/Anaheim.

Jerry

>
> Joe
>
>