Re: [tcpm] TCP tuning
"Biswas, Anumita" <Anumita.Biswas@netapp.com> Wed, 03 February 2010 21:49 UTC
Return-Path: <Anumita.Biswas@netapp.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 0E2C53A6876 for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 13:49:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 TDxgJsunU+By for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 13:49:48 -0800 (PST)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 155CB3A67FE for <tcpm@ietf.org>; Wed, 3 Feb 2010 13:49:48 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.49,400,1262592000"; d="scan'208";a="310728780"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Feb 2010 13:50:31 -0800
Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o13LoVam016344; Wed, 3 Feb 2010 13:50:31 -0800 (PST)
Received: from SACMVEXC2-PRD.hq.netapp.com ([10.99.115.18]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 13:50:31 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 03 Feb 2010 13:50:29 -0800
Message-ID: <A3D02FB7C6883741952C425A59E261A50A4E9EE0@SACMVEXC2-PRD.hq.netapp.com>
In-Reply-To: <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] TCP tuning
Thread-Index: AcqlEqL9ajeA0srbSgGuDYmBpkbAuAAB2F8Q
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com><1e41a3231002031232r6ec9edd3p6367dd9c2581fa08@mail.gmail.com><d1c2719f1002031244g3415c8e1r7d36e26058158d20@mail.gmail.com> <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com>
From: "Biswas, Anumita" <Anumita.Biswas@netapp.com>
To: John Heffner <johnwheffner@gmail.com>, Jerry Chu <hkchu@google.com>
X-OriginalArrivalTime: 03 Feb 2010 21:50:31.0317 (UTC) FILETIME=[E7FA8C50:01CAA51A]
Cc: tcpm@ietf.org
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 21:49:49 -0000
> -----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. > > -John > _______________________________________________ > 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