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

Mark Allman <mallman@icir.org> Fri, 19 November 2010 04:23 UTC

Return-Path: <mallman@icir.org>
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 03BAA3A672F for <tcpm@core3.amsl.com>; Thu, 18 Nov 2010 20:23:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.523
X-Spam-Level:
X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 T3bgmSOVdVR1 for <tcpm@core3.amsl.com>; Thu, 18 Nov 2010 20:23:45 -0800 (PST)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 41BD93A635F for <tcpm@ietf.org>; Thu, 18 Nov 2010 20:23:45 -0800 (PST)
Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAJ4OXSM002600; Thu, 18 Nov 2010 20:24:34 -0800 (PST)
Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BB2EE255A476; Thu, 18 Nov 2010 23:24:33 -0500 (EST)
To: Joe Touch <touch@isi.edu>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <4CE58FED.608@isi.edu>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Who You Are
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma64513-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 18 Nov 2010 23:24:33 -0500
Sender: mallman@icir.org
Message-Id: <20101119042433.BB2EE255A476@lawyers.icir.org>
Cc: 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
Reply-To: mallman@icir.org
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 04:23:46 -0000

> To be more clear, here's the case:
> 
> 	start 1000 connections in a row.
> 
> 	during the first connection, lose some packets and do
> 	normal TCP backoff
> 
> 	so what do the other 999 connections start with?
> 	ans: 10 packets
> 
> The point is that subsequent connections don't do anything
> different.

That is absolutely correct---the subsequent connections do not do
anything differently with a static IW.  But, that may well be perfectly
fine.

E.g., the other 999 connections may be going to 999 different
destinations and the shared portion of the path may not be the problem
and those 999 connections may work perfectly.

E.g., the loss in the first connection may have been transient and even
if the connections are going to the same recipient the same process may
not repeat 999 more times.

And, of course, you're right that the first connection might be telling
of things to come.

Your presumption is that there is much opportunity to share state across
connections and that is useful in preventing issues.  But, thus far this
has all been done with cooked up scenarios.  What is the real
opportunity here?

I'd love an adaptive scheme that got us out of the business of doing our
best to make informed guesses about what the IW should be every so
often.  But, before I buy it I'd have to see some evidence that such a
scheme existed that could really in fact get us out of that business.

allman