Re: [tcpm] TCP tuning
Jerry Chu <hkchu@google.com> Fri, 05 February 2010 01:29 UTC
Return-Path: <hkchu@google.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 155083A6984 for <tcpm@core3.amsl.com>; Thu, 4 Feb 2010 17:29:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.225
X-Spam-Level:
X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 A+lohhbwYlLo for <tcpm@core3.amsl.com>; Thu, 4 Feb 2010 17:29:23 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1BBCB3A68C8 for <tcpm@ietf.org>; Thu, 4 Feb 2010 17:29:23 -0800 (PST)
Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id o151UAFE020226 for <tcpm@ietf.org>; Thu, 4 Feb 2010 17:30:10 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265333410; bh=ck75PHbs8X3qIy2r1S/5WoeLflE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=PDnH/i05R5YSWM91y4Qll+9x+wrN0xfJD5R+KgWai3/5dYfVJaicvQWP0f+aYILMT cD5dIYOiXZNWBc4Qu8Vfg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Mvi55AW9umML2Bi5chtYeSz5e5UX2XfoQEAej01JA4KeTOifQCpwfOO5IL38f7hRt 4y3Ct1Jx29OJKU5AGGOcg==
Received: from pzk30 (pzk30.prod.google.com [10.243.19.158]) by spaceape11.eur.corp.google.com with ESMTP id o151U8GL023175 for <tcpm@ietf.org>; Thu, 4 Feb 2010 17:30:09 -0800
Received: by pzk30 with SMTP id 30so1732777pzk.11 for <tcpm@ietf.org>; Thu, 04 Feb 2010 17:30:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.141.124.18 with SMTP id b18mr1326225rvn.151.1265333407157; Thu, 04 Feb 2010 17:30:07 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1002041458350.4145@ayourtch-lnx.stdio.be>
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <d1c2719f1002031244g3415c8e1r7d36e26058158d20@mail.gmail.com> <133D9897FB9C5E4E9DF2779DC91E947C025F18D6@SLFSNX.rcs.alcatel-research.de> <alpine.DEB.2.00.1002041458350.4145@ayourtch-lnx.stdio.be>
Date: Thu, 04 Feb 2010 17:30:07 -0800
Message-ID: <d1c2719f1002041730l7d89788dgbe8b907f40e3d251@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: ayourtch@cisco.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: tcpm@ietf.org, "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.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: Fri, 05 Feb 2010 01:29:24 -0000
On Thu, Feb 4, 2010 at 6:05 AM, Andrew Yourtchenko <ayourtch@cisco.com> wrote: > > > On Thu, 4 Feb 2010, SCHARF, Michael wrote: > >> Jerry, >> >>>> - A significant increase to the initial window might benefit from >>>> introduction of some form of pacing, since you won't have any ack >>>> clock yet. This might help reduce losses and delay jitter. >>> >>> Agreed. The question is, what is that threshold of >>> window/burst size beyond which pacing is required. My current >>> guess is > 10. >> >> I have the same impression, at least from what I have seen in simulations. >> >> 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. >> >> 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. > > And a possible tweak to this: if we increased the initial window beyond > RFC3390, measure the number of retransmits that have to be done for those > segments. If the stack had to retransmit, then subsequent connection > attempts from the host would need to reduce this "increased" window. Yes we have tried something very similar (dubbed "negative cache"), but discovered its effectiveness depends heavily on a high cache hit, which is difficult in a large server farm behind a stateless load balancer. A small tweak included in the upcoming I-D is to back down to rfc3390 on RW if any burst size (during IW or RW) > 4KB incurs pkt loss. Admittedly this is a smaller and less effective tweak but it doesn't need to maintain any history across different connections. Jerry > > I think this could help to take care of the concern about the short queue > limits on the access-layer equipment. > > > cheers, > andrew > >> >> Michael >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >
- [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