Re: [tcpm] Increasing the Initial Window - Notes

Michael Welzl <michawe@ifi.uio.no> Thu, 11 November 2010 10:39 UTC

Return-Path: <michawe@ifi.uio.no>
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 D43D43A68C6 for <tcpm@core3.amsl.com>; Thu, 11 Nov 2010 02:39:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ZHPFyO+Yx9qO for <tcpm@core3.amsl.com>; Thu, 11 Nov 2010 02:39:28 -0800 (PST)
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 039E93A68C5 for <tcpm@ietf.org>; Thu, 11 Nov 2010 02:39:28 -0800 (PST)
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <michawe@ifi.uio.no>) id 1PGUZN-0004W7-1L; Thu, 11 Nov 2010 11:39:53 +0100
Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from <michawe@ifi.uio.no>) id 1PGUZM-0001FV-ET; Thu, 11 Nov 2010 11:39:52 +0100
Message-Id: <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no>
From: Michael Welzl <michawe@ifi.uio.no>
To: Jerry Chu <hkchu@google.com>
In-Reply-To: <AANLkTik69zRJ7XcWK7ZKCYaHPP0=Z6hnhP1SUnYP=d=8@mail.gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 11 Nov 2010 11:39:31 +0100
References: <20101110152857.GA5094@hell> <AANLkTi=RzbPbVRDQh7y-ydY-P7H16wDri=8EtXP5QuV3@mail.gmail.com> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <AANLkTik69zRJ7XcWK7ZKCYaHPP0=Z6hnhP1SUnYP=d=8@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
X-UiO-Ratelimit-Test: rcpts/h 20 msgs/h 7 sum rcpts/h 24 sum msgs/h 8 total rcpts 4112 max rcpts/h 33 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: AFB40C239C3B7C265BD27B2E43B803B3C08194C3
X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 7 total 126 max/h 7 blacklist 0 greylist 0 ratelimit 0
Cc: tmrg <tmrg-interest@icsi.berkeley.edu>, Mike Belshe <mbelshe@google.com>, Matt Mathis <mattmathis@google.com>, tcpm <tcpm@ietf.org>
Subject: Re: [tcpm] Increasing the Initial Window - Notes
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: Thu, 11 Nov 2010 10:39:30 -0000

On Nov 11, 2010, at 11:36 AM, Jerry Chu wrote:

> On Thu, Nov 11, 2010 at 2:28 AM, Michael Welzl <michawe@ifi.uio.no>  
> wrote:
>>
>> This just gave me an idea:
>>
>> On Nov 11, 2010, at 2:24 AM, Hagen Paul Pfeifer wrote:
>>
>>> * Yuchung Cheng | 2010-11-10 12:04:48 [-0800]:
>>>
>>>> Let's do a reality check: today browsers open tens of flows  
>>>> simultaneously
>>>> to work around small TCP IW (http://www.browserscope.org/  the  
>>>> "network
>>>> tab). A study from AT&T and U of Mich also show 15% TCP flows  
>>>> observed in
>>>> AT&T network already go over IW3. We want to bring this issue to  
>>>> the IETF
>>>> community/experts to stop this downward spiral of sneaky unfair  
>>>> latency
>>>> "tune-ups".
>>>
>>> Let's do a reality check: we talk about TCP not HTTP. ;-) To  
>>> clearify it: the
>>> draft address TCP, including FTP and all protocol built on top of  
>>> TCP. I know
>>> google paradigm is "everything over HTTP" ;) but customers of mine  
>>> do not use
>>> HTTP at all. TCP based file transfer and UDP based protocols are  
>>> the lion
>>> share.
>>
>> I've seen this argumentation again and again, going back and forth.  
>> So it seems that we have a lot of data, and many proponents saying  
>> that it might be worth trying to use IW=10 for the web... but a lot  
>> of people who argue against the IW=10 keep pointing out that HTTP  
>> isn't everything.
>>
>> Why not make this something that could be enabled on a per-socket  
>> basis? I mean, I can decide whether my socket does Nagle or not,  
>> why not let the programmer decide where in the range from 4 to 10  
>> the IW should be, with a socket option or something?
>
> I certainly won't object to this, if that's all it takes for
> standardization. Unfortunately the
> point for the non-convinced is they don't want ANY flows to use IW10
> for fear of hurting
> the performance of their flows.

... but here, your "browsers open tens of flows" argument totally  
holds. How is a web flow with IW10 worse than a browser opening tens  
of flows? If people only use it for the web, like Google has been  
successfully doing, this seems to be quite safe, based on experience.

I'm curious what the opposition says to this  :)

Cheers,
Michael