Re: [tcpm] TCP tuning
Mike Belshe <mike@belshe.com> Thu, 04 February 2010 04:34 UTC
Return-Path: <mike@belshe.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 E9C6A3A69F4 for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 20:34:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 BpX9LBpPrA-2 for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 20:34:34 -0800 (PST)
Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id 389EC3A69EE for <tcpm@ietf.org>; Wed, 3 Feb 2010 20:34:34 -0800 (PST)
Received: by pzk5 with SMTP id 5so3386047pzk.29 for <tcpm@ietf.org>; Wed, 03 Feb 2010 20:35:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.60.14 with SMTP id i14mr375338wfa.261.1265258114344; Wed, 03 Feb 2010 20:35:14 -0800 (PST)
In-Reply-To: <4B69FF69.8040008@isi.edu>
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com> <d1c2719f1002031244g3415c8e1r7d36e26058158d20@mail.gmail.com> <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com> <A3D02FB7C6883741952C425A59E261A50A4E9EE0@SACMVEXC2-PRD.hq.netapp.com> <d1c2719f1002031447w7bd73cb0n290ed1b0e382b140@mail.gmail.com> <4B69FF69.8040008@isi.edu>
Date: Wed, 03 Feb 2010 20:35:14 -0800
Message-ID: <2a10ed241002032035j53029266wb6d3ecf22148d2bf@mail.gmail.com>
From: Mike Belshe <mike@belshe.com>
To: Joe Touch <touch@isi.edu>
Content-Type: multipart/alternative; boundary="00504502bcc574678b047ebedcbe"
Cc: tcpm@ietf.org, "Biswas, Anumita" <Anumita.Biswas@netapp.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: Thu, 04 Feb 2010 05:12:41 -0000
On Wed, Feb 3, 2010 at 2:57 PM, Joe Touch <touch@isi.edu> wrote: > > > Jerry Chu wrote: > > Hi Anumita, > > > > On Wed, Feb 3, 2010 at 1:50 PM, Biswas, Anumita > > <Anumita.Biswas@netapp.com> wrote: > >> > >>> -----Original Message----- > >>> From: John Heffner [mailto:johnwheffner@gmail.com] > >>> Sent: Wednesday, February 03, 2010 12:51 PM > >>> To: Jerry Chu > >>> Cc: tcpm@ietf.org WG > >>> Subject: Re: [tcpm] TCP tuning > >>> > >>> On Wed, Feb 3, 2010 at 3:44 PM, Jerry Chu <hkchu@google.com> wrote: > >>>> Hi John, > >>>> > >>>> On Wed, Feb 3, 2010 at 12:32 PM, John Heffner > >>> <johnwheffner@gmail.com> wrote: > >>>>> A couple thoughts: > >>>>> - A large initial window should probably only be used by mutual > >>>>> agreement. Maybe via a TCP option during the handshake? > >>>> This may not be needed. A receiver can effectively constrain the > >>>> sender's window by advertising a smaller initial receive window. > >>>> > >>>> Obviously this works for only the initial window, not the restart > >>> window. > >>>> (Oh, on a second thought this can be made to work for the restart > >>>> window too.) > >>> A good point, though most receivers (Linux 2.4 and later being the > >>> exception) advertise all available window space, not expecting a large > >>> initial burst from the sender. I think you need a negotiation for > >>> opt-in rather than opt-out. > >> The slow start algorithm tries to probe the network capacity, not the > end node's available window space. The network capacity is dependent on > switch/router queue lengths, among other things and therefore the initial > receive window is not something that can/should be negotiated by end points. > >> > >> However, I do have reservations with standardizing an increased > >> initial window assuming that 10 MSS is a good "guess" for what the > >> network can tolerate > >> > >> I have seen cases where switches topple over initial receive window > >> sizes as spec'd out by RFC 3390. In fact, RFC 3390 does state that the > >> recommended IW value of 4 segments for 1500MSS can cause more loss in > >> networks with higher segment drop rates. > > > > Understood the concern. But sometimes we'll need to take active > > action in order to break the deadlock - TCP spec relying on > > switch/router upgrade while equipment vendors waiting for TCP spec to > > be ratified. > > Let's please be clear that: > > 1) there is NO *urgent* problem > We're talking about an optimization. If we do > nothing, standards-compliant implementations > will continue to work fine. > 2) the benefit and impact need to be considered together, for everyone > I doubt any logic that assumes both: > a) we NEED to make a change for some > AND > b) this will HURT some others > The hypothesis is that init-cwnd was effectively raised long ago by applications (ahem - HTTP) leveraging multiple connections. I'm interested to hear what others think of the hypothesis and how we can prove it to be either true or false. Assuming the hypothesis is true, it doesn't remove the possibility of (2b) above, but it morphs it in interesting ways: a) The same discussions about increasing initial-cwnd have been around for years. So far, TCP changed little, and instead, applications have adapted. Like it or not, the same thing will likely happen as we move forward as long as there are latency benefits to be had. I know that doesn't sound good - I'm just thinking pragmatically. :-) b) Making changes to initial cwnd today will have a multiplicative effect in current software. I can demonstrate that in some cases, initial cwnd is already 40+ because HTTP is using so many connections. So increasing the official initcwnd from 3 to 10 is effectively increasing cwnd to 100+ in some cases. c) It would be sad if, because HTTP worked around this problem by abusing TCP, that new low-latency protocols would have no choice but to replicate current broken behavior to be competitive. Finally, if there is data needed which chromium can assist with gathering, I volunteer to help make it happen. Mike > > TCP is designed to *always* work (as much as possible). It's more > conservative than it needs to be most of the time. Some implementors > take advantage of that, and the tragedy of the commons, and get away > with things that the IETF may not want to endorse for widespread use. > > We really need to see the details to move on. Keep in mind as well that > if you're modifying TCP, taking the time to document your proposal (no, > an extended set of slides is not documentation) is a good indication of > your overall diligence (and vice versa). > > Joe > > > _______________________________________________ > 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