Re: [tcpm] TCP tuning

Joe Touch <touch@ISI.EDU> Wed, 03 February 2010 17:43 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 46DA13A6C8E for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 09:43:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 yBctb6eu9gZy for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 09:43:10 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 69D783A6898 for <tcpm@ietf.org>; Wed, 3 Feb 2010 09:43:10 -0800 (PST)
Received: from [70.213.181.125] (125.sub-70-213-181.myvzw.com [70.213.181.125]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o13Hh9NS026956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 09:43:11 -0800 (PST)
Message-ID: <4B69B5AC.1090209@isi.edu>
Date: Wed, 03 Feb 2010 09:43:08 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Michael Welzl <michawe@ifi.uio.no>
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <4B69A53E.2050508@isi.edu> <4B69ACD9.1030105@sun.com> <4B69AE64.8070608@isi.edu> <10EDB15A-0DF6-45EE-897C-E38AA611134C@ifi.uio.no> <4B69B030.3000508@isi.edu> <D70C30EF-91E3-4DB6-B0C7-0A6328C77E6A@ifi.uio.no>
In-Reply-To: <D70C30EF-91E3-4DB6-B0C7-0A6328C77E6A@ifi.uio.no>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigF5D6B57E25A285BCA2BCBCC4"
X-MailScanner-ID: o13Hh9NS026956
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, Kacheong Poon <kacheong.poon@sun.com>
Subject: Re: [tcpm] TCP tuning
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: Wed, 03 Feb 2010 17:43:11 -0000

Hi, Michael,

Michael Welzl wrote:
>> Michael Welzl wrote:
>>>> Agreed. The point is to what extent TCP is modified for fractional
>>>> benefits for specific communities. TCP is "optimized" to always work,
>>>> but not to work especially well in any particular environment.
>>>
>>> Yeah... stupid, isn't it?
>>
>> I'll trade "always" or even "usually" to "works very well in some
>> places, but not at all in others".
>>
>> Making TCP smarter is fine; doing so at the expense of robustness is not.
> 
> Sorry for being so unspecific - I was just thinking out loud...
> my point was: isn't that actually a stupid situation?
> 
> Why do we have to worry about TCP over wireless, when so
> many users know perfectly well that their access link is WiFi?
> Why do we have to worry so much about raising the window
> when it's perfectly clear in some cases (at least from the
> combined knowledge of the stack + its users) that a certain
> connection is only going to face high bandwidth conditions?
> 
> In other words, why not harness this knowledge somehow,
> and develop a customized transport protocol, or ways of
> customizing what we now have?

That's been tried in various ways in various IETF efforts. Some try to
find the properties of the immediate link, which are expected for some
link types to dominate the path. Some try to detect path properties.
Some reuse information from past connections.

None of that is all that bad.

...
> To get back to the point, I'm not seriously suggesting to reduce
> TCP's robustness and I'm in your camp about the larger
> window thing. My personal opinion here is that, however,
> the current slow start is indeed questionable, and questioning
> it should be done, in large scale thorough experiments. I'm
> interested in this and started some such work with a master
> student; I might continue if I get another one (or if I can nicely
> make that fit as a part of a larger Ph.D. thesis - ideas for
> how to do that are welcome!  :-)  )

I think revising congestion control to be smarter is already a IRTF
effort (aren't you active in that already?):

http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG

IMO, I would encourage Google to take their work there and get feedback
there first. TCPM is a place where mature, vetted ideas should be
considered, preferably (IMO).

Joe