Re: [tcpm] Increasing the Initial Window - Notes

"Scheffenegger, Richard" <rs@netapp.com> Thu, 11 November 2010 12:26 UTC

Return-Path: <rs@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 51B463A68F2 for <tcpm@core3.amsl.com>; Thu, 11 Nov 2010 04:26:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.515
X-Spam-Level:
X-Spam-Status: No, score=-10.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 faqKW8H-HtN4 for <tcpm@core3.amsl.com>; Thu, 11 Nov 2010 04:26:51 -0800 (PST)
Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id A1E853A6899 for <tcpm@ietf.org>; Thu, 11 Nov 2010 04:26:50 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.59,183,1288594800"; d="scan'208";a="219005778"
Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 11 Nov 2010 04:27:19 -0800
Received: from ldcrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oABCRFLY005555; Thu, 11 Nov 2010 04:27:19 -0800 (PST)
Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 12:27:18 +0000
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: Thu, 11 Nov 2010 12:27:17 -0000
Message-ID: <5FDC413D5FA246468C200652D63E627A0B65CAD6@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <AANLkTimdoQLBtww720bpJnVAHUuFNTngOp-8Zp2kiqXN@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] Increasing the Initial Window - Notes
Thread-Index: AcuBj4Z/Ibn4v6ZoQEid3hB4+9E5lAACn1Og
References: <20101110152857.GA5094@hell><AANLkTi=RzbPbVRDQh7y-ydY-P7H16wDri=8EtXP5QuV3@mail.gmail.com><20101111012453.GB2691@hell><29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no><AANLkTik69zRJ7XcWK7ZKCYaHPP0=Z6hnhP1SUnYP=d=8@mail.gmail.com><824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no><4CDBCA4E.8000705@tlc.polito.it> <AANLkTimdoQLBtww720bpJnVAHUuFNTngOp-8Zp2kiqXN@mail.gmail.com>
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Jerry Chu <hkchu@google.com>, Marco Mellia <mellia@tlc.polito.it>
X-OriginalArrivalTime: 11 Nov 2010 12:27:18.0990 (UTC) FILETIME=[C84266E0:01CB819B]
Cc: tmrg <tmrg-interest@icsi.berkeley.edu>, Mike Belshe <mbelshe@google.com>, tcpm <tcpm@ietf.org>, Matt Mathis <mattmathis@google.com>, Michael Welzl <michawe@ifi.uio.no>
Subject: Re: [tcpm] Increasing the Initial Window - Notes
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, 11 Nov 2010 12:26:52 -0000

Jerry,


After some thoughts, I have the following summarization for me:

Simulating small pipes is very tricky (concerns about timing effects of simulator, selection of queuing parameters which are realistic...)

Traffic rarely comes in via 1GE, and drops down to a 64kbps bottleneck link. Only in the direction homeuser->webserver this huge bandwidth disparity might be encountered in a single step (but even then I doubt it).

Web server traffic probably runs over a series of shrinking pipes (ie 10G/1G/OC12/OC3/T3/T1/64k) - so in the typical web server environment, even if each link has only small buffers, the server->homeuser direction will less likely show bad effects I would think. Which alignes with the data you presented at ICCSG, correct?

Deploying IW10 with NewReno shows almost the same benefits as with Linux SACK (within 10% of the numbers shown). AFAIK, Linux Newreno is fairly standards-compatible (at least much more than Linux SACK). 


For the record, based on my comments regarding non-web traffic, I'm in support for this proposal, even though I think it should not be deployed just by itself. 

I would like to know if the pacing suggestion would make a difference for the opposition, as that would result in a natural limit of the burstiness and IW (even beyond 10)?

Regards,

Richard Scheffenegger
 

> -----Original Message-----
> From: Jerry Chu [mailto:hkchu@google.com] 
> Sent: Donnerstag, 11. November 2010 11:59
> To: Marco Mellia
> Cc: tcpm; Mike Belshe; tmrg; Matt Mathis; Michael Welzl
> Subject: Re: [tcpm] Increasing the Initial Window - Notes
> 
> On Thu, Nov 11, 2010 at 2:49 AM, Marco Mellia 
> <mellia@tlc.polito.it> wrote:
> >
> >
> >>> I certainly won't object to this, if that's all it takes for 
> >>> standardization. Unfortunately the point for the non-convinced is 
> >>> they don't want ANY flows to use IW10 for fear of hurting the 
> >>> performance of their flows.
> >>
> >> ... but here, your "browsers open tens of flows" argument 
> totally holds. How is a web flow with IW10 worse than a 
> browser opening tens of flows? If people only use it for the 
> web, like Google has been successfully doing, this seems to 
> be quite safe, based on experience.
> >>
> >> I'm curious what the opposition says to this  :)
> >
> > If today a brower opens 10 flows with a server using IW=1 
> you gets 10 packets equivalent IW.
> > Increasing the IW to 10 leads to an equivalent IW of 100 
> packets. At that point, you DSL modem will definitively start 
> dropping most of them...
> 
> But if we don't start thinking about how to scale these TCP 
> parameters, tomorrow (ok, maybe in a couple of years) when 
> browsers decide to open 20 or 30 flows because they are 
> frustrated with low TCP parameters like IW, it will 
> effectively be equivalent to increasing IW to 10 today.
> So do we want to do nothing and leave it all to apps, or try 
> to take some control of some key TCP parameters back into TCP itself?
> 
> Jerry
> 
> >
> > --
> >
> > Ciao,                    /\/\/\rco
> >
> > +-----------------------------------+
> > | Marco Mellia - Assistant Professor|
> > | Skypeid: mgmellia                 |
> > | Tel: +39-011-564-4173             |
> > | Cel: +39-340-9674888              |   /"\  .. . . . . . . 
> . . . . . .
> > | Politecnico di Torino             |   \ /  . ASCII Ribbon 
> Campaign  .
> > | Corso Duca degli Abruzzi 24       |    X   .- NO HTML/RTF 
> in e-mail .
> > | Torino - 10129 - Italy            |   / \  .- NO Word 
> docs in e-mail.
> > | http://www.telematica.polito.it   |        .. . . . . . . 
> . . . . . .
> > +-----------------------------------+
> > The box said "Requires Windows 95 or Better." So I installed Linux.
> >
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>