IETF Logo Mail Archive

Re: [tcpm] TCP tuning

Kacheong Poon <kacheong.poon@sun.com> Wed, 03 February 2010 16:13 UTC

Return-Path: <kacheong.poon@sun.com>
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 CA5E33A6B18 for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 08:13:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level:
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 tdtZJUK6iZbt for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 08:13:08 -0800 (PST)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id C0CDF3A6AF8 for <tcpm@ietf.org>; Wed, 3 Feb 2010 08:13:08 -0800 (PST)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o13GDpTf007251 for <tcpm@ietf.org>; Wed, 3 Feb 2010 16:13:51 GMT
Received: from [10.7.251.223] (punchin-kcpoon.SFBay.Sun.COM [10.7.251.223]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o13GDnDn195717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tcpm@ietf.org>; Wed, 3 Feb 2010 08:13:50 -0800 (PST)
Message-ID: <4B69A0BD.2060708@sun.com>
Date: Thu, 04 Feb 2010 00:13:49 +0800
From: Kacheong Poon <kacheong.poon@sun.com>
Organization: Sun Microsystems, Inc.
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100115 Thunderbird/3.0.1
MIME-Version: 1.0
To: tcpm@ietf.org
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de>
In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 16:13:09 -0000

On 02/ 3/10 11:17 PM, SCHARF, Michael wrote:

> In the past, I have played a little bit with an initial window e. g. of
> 10 MSS, and that worked surprisingly well. Also, one could combine a
> larger initial window with other mechanisms that would reduce the
> aggressiveness of the flow startup. Maybe it is indeed time to think
> about the Slow-Start once again.


FWIW, I've come across traces showing some network equipment
uses an initial window as large as 16 segments (some kind of
turbo mode).  It is probably true many stacks already use a
much larger initial window than recommended in the RFC.  Just
that people have been very quiet about this.



-- 

						K. Poon.
						kacheong.poon@sun.com

v2.23.0 | Report a Bug | By Email