Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes

Fred Baker <fred@cisco.com> Tue, 16 November 2010 14:09 UTC

Return-Path: <fred@cisco.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 E5C5C3A69F3 for <tcpm@core3.amsl.com>; Tue, 16 Nov 2010 06:09:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.18
X-Spam-Level:
X-Spam-Status: No, score=-110.18 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 2rR3qrv+SAfV for <tcpm@core3.amsl.com>; Tue, 16 Nov 2010 06:09:10 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 18E793A688E for <tcpm@ietf.org>; Tue, 16 Nov 2010 06:09:10 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAMMf4kxAaMHG/2dsb2JhbACiX3GjPZslhUsEhFiGAIMM
X-IronPort-AV: E=Sophos;i="4.59,206,1288569600"; d="scan'208";a="620931565"
Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 16 Nov 2010 14:09:52 +0000
Received: from Freds-Computer.local (hkidc-vpn-client-235-169.cisco.com [10.75.235.169]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAGE9k3J024471; Tue, 16 Nov 2010 14:09:51 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 16 Nov 2010 22:09:51 +0900
X-PGP-Universal: processed; by Freds-Computer.local on Tue, 16 Nov 2010 22:09:51 +0900
Mime-Version: 1.0 (Apple Message framework v1082)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <alpine.DEB.2.00.1011161345170.11898@wel-95.cs.helsinki.fi>
Date: Tue, 16 Nov 2010 22:09:38 +0800
Message-Id: <E798B9A8-29BB-425B-B0C2-2B2735C49948@cisco.com>
References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <AANLkTim7g=XqfSMHpHVbw1qqPOL-oNApt2i_2RCt0SCi@mail.gmail.com> <AD2BFE84-CA5B-4CDC-8822-1FC2713E3AE0@cisco.com> <alpine.DEB.2.00.1011161345170.11898@wel-95.cs.helsinki.fi>
To: "\"Ilpo Järvinen\"" <ilpo.jarvinen@helsinki.fi>
X-Mailer: Apple Mail (2.1082)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: tcpm <tcpm@ietf.org>, tmrg <tmrg-interest@ICSI.Berkeley.EDU>
Subject: Re: [tcpm] [Tmrg] 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: Tue, 16 Nov 2010 14:09:11 -0000

On Nov 16, 2010, at 10:01 PM, Ilpo Järvinen wrote:

> On Tue, 16 Nov 2010, Fred Baker wrote:
> 
>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:
>> 
>>> I wonder what factors will argue that the initial quantum can't be changed?
>>> Someone has argued in the past IW10 effectively "disable CC algorithm".
>>> But haven't we already done that years ago when moving up IW from 1 to 3 if
>>> one insisted then that the initial quantum must be 1?
>> 
>> Actually, no. I may be the person who said that this effectively 
>> disables congestion control in the average case; my reason for saying 
>> that is that per what little data I have, the average TCP transfer is on 
>> the order of 15K bytes, which is about ten 1460 byte segments. 
> 
> It only "disables" it if there was no congestion to control in the first 
> place.

How do you turn off something that's not on?

I refer to this as in the average case turning off congestion control because the transmission requires ten data packets and they all get sent in a single burst. There is no congestion control, with IW=10, in the case of the average-sized (which is actually gar above the median-sized) file transfer.

> Could you on your behalf answer how does IW=3 affect parallel sessions on 
> the same kind of environment? ...I've done research on this (and Jerry has 
> too) and I know that the answer is not an intuitive one. Then we changed 
> to IW10 in the same environment and observe no (consistent) change. The 
> results are driven by problems already with IW3 so IW10 won't make it any 
> worse or the effect is just too small to be measured among the other 
> troubles that happen.

That may be true. I have asked to see data describing the impact. I haven't seen the data. Maybe I missed something?