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

Lachlan Andrew <lachlan.andrew@gmail.com> Mon, 15 November 2010 23:57 UTC

Return-Path: <lachlan.andrew@gmail.com>
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 062CE28C1F7 for <tmrg@core3.amsl.com>; Mon, 15 Nov 2010 15:57:13 -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=[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 oyNZ7LqaR0UZ for <tmrg@core3.amsl.com>; Mon, 15 Nov 2010 15:57:06 -0800 (PST)
Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by core3.amsl.com (Postfix) with ESMTP id 104CA28C1E0 for <tmrg@irtf.org>; Mon, 15 Nov 2010 15:57:02 -0800 (PST)
Received: by yxh35 with SMTP id 35so32526yxh.13 for <tmrg@irtf.org>; Mon, 15 Nov 2010 15:57:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=gmail.com; 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 10.42.178.6 with SMTP id bk6mr1246925icb.80.1289865463650; Mon, 15 Nov 2010 15:57:43 -0800 (PST)
Received: by 10.231.173.210 with HTTP; Mon, 15 Nov 2010 15:57:43 -0800 (PST)
In-Reply-To: <20101115204109.C9C0324D1DAB@lawyers.icir.org>
References: <AANLkTi=+aK5W0YqWMzZMZ7NGJSBAjDqw=b6ZOruUyosC@mail.gmail.com> <20101115204109.C9C0324D1DAB@lawyers.icir.org>
Date: Mon, 15 Nov 2010 15:57:43 -0800
Message-ID: <AANLkTi=nQOc0WszDC0tNA3fAJo4Ag6pKkLzK9cCkDCR4@mail.gmail.com>
From: Lachlan Andrew <lachlan.andrew@gmail.com>
To: mallman <mallman@icir.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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
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: Mon, 15 Nov 2010 23:57:13 -0000

On 15 November 2010 12:41, Mark Allman <mallman@icir.org> wrote:
>
>> On 13 November 2010 04:01, Stefan Hirschmann <krasnoj@gmx.at> 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
has?"

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.

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837