Re: [tcpm] TCP tuning

Michael Welzl <michawe@ifi.uio.no> Wed, 03 February 2010 18:26 UTC

Return-Path: <michawe@ifi.uio.no>
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 688AB28C1A8 for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 10:26:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611]
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 CE5HpG+HsoNg for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 10:26:47 -0800 (PST)
Received: from get-mta-out02.get.basefarm.net (smtp.getmail.no [84.208.15.66]) by core3.amsl.com (Postfix) with ESMTP id 827A228C107 for <tcpm@ietf.org>; Wed, 3 Feb 2010 10:26:47 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Received: from smtp.getmail.no ([10.5.16.4]) by get-mta-out02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA006MZ39TXAA0@get-mta-out02.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 19:27:29 +0100 (MET)
Received: from [192.168.0.194] ([84.208.136.71]) by get-mta-in02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KXA000B53979W30@get-mta-in02.get.basefarm.net> for tcpm@ietf.org; Wed, 03 Feb 2010 19:27:29 +0100 (MET)
X-PMX-Version: 5.5.3.366731, Antispam-Engine: 2.7.0.366912, Antispam-Data: 2010.2.3.180920
Message-id: <8FCC1879-FBA4-4A5F-8ADF-932A6731B7EA@ifi.uio.no>
From: Michael Welzl <michawe@ifi.uio.no>
To: Joe Touch <touch@isi.edu>
In-reply-to: <4B69B5AC.1090209@isi.edu>
Date: Wed, 03 Feb 2010 19:27:07 +0100
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> <4B69B5AC.1090209@isi.edu>
X-Mailer: Apple Mail (2.936)
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 18:26:48 -0000

>> 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.

Really? I'd be curious about a few pointers, what exactly
do you have in mind? About reusing information etc., the
congestion manager and your TCB sharing stuff comes to
mind, but for the rest I'm curious


>> 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?):

Yep - I just thought out loud on this list because that's
where the discussion happened...


> 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).

I absolutely agree.

Cheers,
Michael