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

Lachlan Andrew <> Mon, 15 November 2010 23:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 062CE28C1F7 for <>; Mon, 15 Nov 2010 15:57:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oyNZ7LqaR0UZ for <>; Mon, 15 Nov 2010 15:57:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 104CA28C1E0 for <>; Mon, 15 Nov 2010 15:57:02 -0800 (PST)
Received: by yxh35 with SMTP id 35so32526yxh.13 for <>; Mon, 15 Nov 2010 15:57:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F/xmPO0N+iu1WLwCnyVKtTlU2czAZJFkad1jC6OWRcA=; b=fjjgG/dbVFxu3W7nZ/lS3LUJLOMu06BXTzv+zcnzF5ihCLX2D+m5/qQis+cBrhEa6s 8q0jNZH94bMlZa0AhzbVchxQY67kjV0ExsfxCAkeD+sUPM2bUuxAR4up0m1WMO0ZVSgX wSHWmdui0DijN6io2vO69eV6Q8N6JTtnKNMgs=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tfIzhFIyT2fFH6zac3JvJZapv0oz++Pj17d+mggqE+s9vxXpfeopfF/dj44vSDaXWm M6oRu4Qgy87sMg7NcZUXz6tANxOVtxD0vctdyhSNa6Zt2Jz+me7vzHA5y9ZFPV9IqOAd l2pTmMpjXJEw+DUJ5IAHkD1Ku844FmVneb5JY=
MIME-Version: 1.0
Received: by with SMTP id bk6mr1246925icb.80.1289865463650; Mon, 15 Nov 2010 15:57:43 -0800 (PST)
Received: by with HTTP; Mon, 15 Nov 2010 15:57:43 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Mon, 15 Nov 2010 15:57:43 -0800
Message-ID: <>
From: Lachlan Andrew <>
To: mallman <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: tmrg <>, tcpm <>
Subject: Re: [tmrg] [Tmrg] [tcpm] Increasing the Initial Window - Notes
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF's transport modeling research group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Nov 2010 23:57:13 -0000

On 15 November 2010 12:41, Mark Allman <> wrote:
>> On 13 November 2010 04:01, Stefan Hirschmann <> wrote:
>> >
>> > To be honest. I don't like the idea that an application behaves
>> > different depending on the used TCP variant. For me, TCP is kernel
>> > stuff and an application should use it without thinking.
>> Applications very often check the version of OS or CPU they are
>> running on, and behave differently accordingly.  Doing this for TCP
>> wouldn't be setting a precedent.
> I am not sure that analogy holds.  An app that looks at the OS or the
> CPU can get a complete story of what's up.  Checking on TCP seems a
> little more tenuous because it isn't really TCP that we're concerned
> about, but rather the state of the path relative to the TCP config.
> And, its hard to understand the state of the path.

I agree the application shouldn't follow the TCP state, but that is
different from adapting to which variant is used.  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

Of course, it isn't that simple, because the work-around of opening
many connections may give selfish users additional benefits even if
underlying issues are fixed and so the incentives are wrong.  However,
I don't see a problem in principle with an app adapting to the flavour
of TCP, any more than an app getting a choice of DCCP congestion
control algorithm, or using DCCP if it is available and UDP otherwise.


Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
Ph +61 3 9214 4837