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

Joe Touch <touch@isi.edu> Fri, 19 November 2010 17:23 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 6218C3A6860 for <tcpm@core3.amsl.com>; Fri, 19 Nov 2010 09:23:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NMUGhJgIwi81 for <tcpm@core3.amsl.com>; Fri, 19 Nov 2010 09:23:02 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 9D2583A67E1 for <tcpm@ietf.org>; Fri, 19 Nov 2010 09:23:02 -0800 (PST)
Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oAJHN2SO028539 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 19 Nov 2010 09:23:11 -0800 (PST)
Message-ID: <4CE6B276.6040602@isi.edu>
Date: Fri, 19 Nov 2010 09:23:02 -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: Jerry Chu <hkchu@google.com>
References: <20101110152857.GA5094@hell> <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> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <AANLkTik3MpEyOZ+EWdtD8C+e2m3BrgKXK0KJrSoF=DMO@mail.gmail.com> <4CE597AB.1020306@isi.edu> <AANLkTikQK2diSib+U3bgyMpkurdojQip24M+3m9aA2we@mail.gmail.com>
In-Reply-To: <AANLkTikQK2diSib+U3bgyMpkurdojQip24M+3m9aA2we@mail.gmail.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: "Anantha Ramaiah (ananth)" <ananth@cisco.com>, tcpm <tcpm@ietf.org>, David Borman <david.borman@windriver.com>
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: Fri, 19 Nov 2010 17:23:03 -0000

Hi, Jerry (et al.),

The logic here is astounding.

We can't use a reactive system because it would make the wrong decision, 
and potentially treat all endpoints the wrong way.

So let's make a static decision that is, essentially, the same as the 
automatic one with particular parameters (A=0, M=1, timescale=infinite, 
aggregation=all). Alternately, for Mark's proposal, that would be (A=+k, 
M=1, timescale=every few years, aggregation=all).

I conclude that:

	- if there is no objective metric for the safety of this
	change, it MUST NOT be deployed

	- if there is an objective metric for its safety, it's surely
	more safe to incorporate that as a test

Even if all the 'auto' system does is backoff to IW=3 if IW=10 causes 
persistent problems, that's MUCH SAFER than anything else.

If, as Mark concludes, an auto system isn't ready for prime time because 
we don't know the impact, then surely we don't have enough info for a 
static configuration of that auto system either.

Joe