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

David Borman <david.borman@windriver.com> Thu, 18 November 2010 20:32 UTC

Return-Path: <david.borman@windriver.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 DE4BA3A6811 for <tcpm@core3.amsl.com>; Thu, 18 Nov 2010 12:32:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.519
X-Spam-Level:
X-Spam-Status: No, score=-103.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 CagEya3Nll8f for <tcpm@core3.amsl.com>; Thu, 18 Nov 2010 12:32:02 -0800 (PST)
Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 17ACB3A6834 for <tcpm@ietf.org>; Thu, 18 Nov 2010 12:32:02 -0800 (PST)
Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id oAIKWm2v006745; Thu, 18 Nov 2010 12:32:48 -0800 (PST)
Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Nov 2010 12:32:47 -0800
Received: from [172.25.44.11] ([172.25.44.11]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Nov 2010 12:32:47 -0800
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: David Borman <david.borman@windriver.com>
In-Reply-To: <4CE585E9.6060203@isi.edu>
Date: Thu, 18 Nov 2010 14:32:45 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.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> <E798B9A8-29BB-425B-B0C2-2B2735C49948@cisco.com> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.1082)
X-OriginalArrivalTime: 18 Nov 2010 20:32:47.0773 (UTC) FILETIME=[C34234D0:01CB875F]
Cc: tcpm <tcpm@ietf.org>
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: Thu, 18 Nov 2010 20:32:03 -0000

On Nov 18, 2010, at 2:00 PM, Joe Touch wrote:

> Hi, all,
> 
> On 11/18/2010 4:46 AM, David Borman wrote:
>> 
>> On Nov 17, 2010, at 2:41 PM, Jakob Heitz wrote:
>> 
>>> IMHO:
>>> 
>>> If you think a small TCP IW is protecting any network from
>>> congestion collapse, you are either living in the past
>>> or under delusions of grandeur.
>> 
>> That is my point, increasing the TCP IW may increase congestion and
>> packet drops in some scenarios, but it doesn't change how TCP reacts to
>> congestion ...
> 
> Actually, it does.
> 
> Consider that there are three cases:
> 
> A) connections so small the IW doesn't matter (they already fit in IW=3)
> 
> B) connections 4-20 or so segments range
> 
> C) connections much longer than 20 or so segments
> 
> (A) isn't affected by this proposed change at all, so we don't need to consider it.
> 
> (C) adjusts to the IW using AIMD, so even if we guess wrong, TCP will "react to congestion" here.
> 
> And then there's (B). (B) doesn't react to congestion. Every new connection uses IW=10. Even after repeated attempts - to a given address, or, e.g., to every address - end up dropping, e.g., half of those segments. (B) will sit there and beat its head against the wall.

> 
> That's the congestion-increasing case. Will this cause collapse? I don't know. But it's definitely NOT reacting to congestion.

No, (B) will also react to congestion, if the congestion causes packet loss.  For any given flow, if all the packets get through the first time, from it's viewpoint there is no congestion.  If they don't all get through, that connection does normal TCP backoff and retransmits.  It's not really any different than if the connection had started with IW=3, worked it's way up to IW=10, and *then* the network became congested.  If there is congestion and packet loss, those TCP streams affected by the packet loss will all be backing off.  The flows that don't have dropped packets complete and go away.

			-David Borman

> 
> 
> So can we please get off the long-connection case? That's not the issue here at all*...
> 
> Joe
> 
> PS - * even long connections can be affected by the IW, e.g., when they do a restart after idle, if they use IW for the restart value repeatedly; that's worth considering, but should be considered roughly the same as (B) if each busy period is in the 4-20 segments range. I.e., we can just talk about (B), IMO.
>