Re: [tcpm] TCP tuning

Kacheong Poon <kacheong.poon@sun.com> Thu, 04 February 2010 11:37 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 7151828C0EF for <tcpm@core3.amsl.com>; Thu, 4 Feb 2010 03:37:20 -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 d+rPnCggMHEr for <tcpm@core3.amsl.com>; Thu, 4 Feb 2010 03:37:19 -0800 (PST)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 8D10728C126 for <tcpm@ietf.org>; Thu, 4 Feb 2010 03:37:19 -0800 (PST)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o14Bc4q0023185 for <tcpm@ietf.org>; Thu, 4 Feb 2010 11:38:04 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 o14Bc2lh373456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tcpm@ietf.org>; Thu, 4 Feb 2010 03:38:04 -0800 (PST)
Message-ID: <4B6AB199.2020701@sun.com>
Date: Thu, 04 Feb 2010 19:38:01 +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> <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> <d1c2719f1002031225w24f1bb2anf89467fffe8e5971@mail.gmail.com> <316A6EC9-03FF-4A11-9E1E-084220A8146A@ifi.uio.no>
In-Reply-To: <316A6EC9-03FF-4A11-9E1E-084220A8146A@ifi.uio.no>
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: Thu, 04 Feb 2010 11:37:20 -0000

On 02/ 4/10 06:10 AM, Michael Welzl wrote:

> Without trying to get into a debate on engineering vs. research, I would
> say that the research community's perception of TCP research is that,
> indeed, such a change is a valid research question. That's not because
> of a need to find the "best, elegant, risk free solution", but because
> of the need to make sure that it's a solution that's safe to deploy.
>
> This is indeed at odds with needs for timeliness - but your need for
> that can't be the basis for lowering the bar about significant changes
> to TCP in the IETF.


Something interesting to "chit-chat" during coffee break...  I
think the history of the current RFC 3390 limit is like the
following.  Please correct me if I am wrong.

The original limit was 1.  But because of an implementation mistake
in BSD, the reality was actually 2.  And IETF accepted the reality.
Then folks realized that during slow start, TCP almost always sent
a burst of 3 segments because of delayed ACK.  So people thought that
around 4380 (3 * 1460 bytes which is a common segment size) was fine
and came up with a formula as in RFC 3390.

Just wondering, if there were no bug, would the initial cwnd be
increased almost 10 years ago?  Note that I am not trying to start
a debate on history nor reality vs research ;-)



-- 

						K. Poon.
						kacheong.poon@sun.com