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

Joe Touch <touch@isi.edu> Thu, 18 November 2010 20:01 UTC

Return-Path: <touch@isi.edu>
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 239E428C103 for <tcpm@core3.amsl.com>; Thu, 18 Nov 2010 12:01:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level:
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, 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 bxZ3PlBSpqSA for <tcpm@core3.amsl.com>; Thu, 18 Nov 2010 12:01:22 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id A28D928C112 for <tcpm@ietf.org>; Thu, 18 Nov 2010 12:01:14 -0800 (PST)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oAIK0fjl007655 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 12:00:41 -0800 (PST)
Message-ID: <4CE585E9.6060203@isi.edu>
Date: Thu, 18 Nov 2010 12:00:41 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: David Borman <david.borman@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>
In-Reply-To: <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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:01:23 -0000

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.

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.