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

Mark Allman <mallman@icir.org> Tue, 16 November 2010 01:58 UTC

Return-Path: <mallman@icir.org>
X-Original-To: tmrg@core3.amsl.com
Delivered-To: tmrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135CC3A6D82 for <tmrg@core3.amsl.com>; Mon, 15 Nov 2010 17:58:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.449
X-Spam-Level:
X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ggjpC-Z+XsWR for <tmrg@core3.amsl.com>; Mon, 15 Nov 2010 17:58:43 -0800 (PST)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id E62943A6D81 for <tmrg@irtf.org>; Mon, 15 Nov 2010 17:58:42 -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 oAG1uV7N018076; Mon, 15 Nov 2010 17:56:32 -0800 (PST)
Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B67C624D6257; Mon, 15 Nov 2010 20:56:31 -0500 (EST)
To: Lachlan Andrew <lachlan.andrew@gmail.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <AANLkTi=nQOc0WszDC0tNA3fAJo4Ag6pKkLzK9cCkDCR4@mail.gmail.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Back in the Saddle
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma58572-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 15 Nov 2010 20:56:31 -0500
Sender: mallman@icir.org
Message-Id: <20101116015631.B67C624D6257@lawyers.icir.org>
Cc: tmrg <tmrg@irtf.org>, tcpm <tcpm@ietf.org>
Subject: Re: [tmrg] [Tmrg] [tcpm] Increasing the Initial Window - Notes
X-BeenThere: tmrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mallman@icir.org
List-Id: IRTF's transport modeling research group <tmrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/tmrg>, <mailto:tmrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/tmrg>
List-Post: <mailto:tmrg@irtf.org>
List-Help: <mailto:tmrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/tmrg>, <mailto:tmrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2010 01:58:44 -0000

> I thought the issue was "If we fix problem X of TCP (very slow to
> start), should applications be able to test whether that fix has been
> made, and disable their old work-arounds (opening multiple
> connections) if it has?"

OK.  So, the client wants to issue small requests to some server and
expects content in return (a la HTTP).  How many connections should it
open?  The server controls the initial cwnd that matters and the client
controls the number of parallel connections.

allman