Re: [tcpm] TCP tuning
Kacheong Poon <kacheong.poon@sun.com> Thu, 04 February 2010 16:27 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 B85E73A6B1E for <tcpm@core3.amsl.com>; Thu, 4 Feb 2010 08:27:57 -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 7x3E6uYBkL3b for <tcpm@core3.amsl.com>; Thu, 4 Feb 2010 08:27:57 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id DFEB23A69ED for <tcpm@ietf.org>; Thu, 4 Feb 2010 08:27:56 -0800 (PST)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o14GSgo8025404 for <tcpm@ietf.org>; Thu, 4 Feb 2010 16:28:43 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 o14GSf0K403553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tcpm@ietf.org>; Thu, 4 Feb 2010 08:28:42 -0800 (PST)
Message-ID: <4B6AF5B8.60607@sun.com>
Date: Fri, 05 Feb 2010 00:28:40 +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> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <d1c2719f1002031244g3415c8e1r7d36e26058158d20@mail.gmail.com> <133D9897FB9C5E4E9DF2779DC91E947C025F18D6@SLFSNX.rcs.alcatel-research.de>
In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C025F18D6@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: Thu, 04 Feb 2010 16:27:57 -0000
On 02/ 4/10 09:35 PM, SCHARF, Michael wrote: > Yet, one could think of a very simple form of pacing with a single timer that changes the Slow-Start only when it "hurts" - I think that I have mentioned this possibility on this list before: > > In this approach, the initial window remains at the value given by RFC 3390. But the sender is allowed to further increase the window after a certain time (say, 100ms), but only > if the RTT is known to be larger than 100ms (as measured e. g. during handshake), if no ACK has been received until then, and if recently there have been no signs of congestion to this destination. For a server, it may just have 1 sample of RTT (the ACK for its SYN/ACK). Is this enough to determine much? Suppose the ACK for the SYN/ACK is lost, and the server gets a request (data + ACK for the SYN/ACK) instead, can it distinguish this case from the case when a client can bundle data in third leg of 3-way handshake? And it seems to defeat much of the benefits of increasing the initial cwnd if the server needs to wait 100ms before sending more. > The advantage of this approach is that TCP uses the larger initial window only if the RTT is larger than 100ms (or whatever threshold is defined). On the one hand, this reduces the performance problems that can be observed for RTTs of the order of 200ms. But, on the other hand, flows with a smaller RTT would use the existing Slow-Start, i. e., the faster startup is only used by a small number of flows and thus be much less disruptive than a general revision of RFC 3390. > > A simpler variant of this idea is to allow an increased initial window beyond RFC 3390 if the measured RTT is larger than a certain threshold such as 100ms. -- K. Poon. kacheong.poon@sun.com
- [tcpm] TCP tuning Lars Eggert
- Re: [tcpm] TCP tuning Adam Langley
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning Stefanos Harhalakis
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Adam Langley
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Biswas, Anumita
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Biswas, Anumita
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Murali Bashyam
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Marco Mellia
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mike Belshe
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Alexander Zimmermann
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning Andrew Yourtchenko
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mike Belshe
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Joe Touch