Re: [tcpm] Increasing the Initial Window - Notes

"Scheffenegger, Richard" <rs@netapp.com> Sat, 13 November 2010 18:13 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 932C23A6C10 for <tcpm@core3.amsl.com>; Sat, 13 Nov 2010 10:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.53
X-Spam-Level:
X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 cuN1nggjFVal for <tcpm@core3.amsl.com>; Sat, 13 Nov 2010 10:13:17 -0800 (PST)
Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 679BE3A6C07 for <tcpm@ietf.org>; Sat, 13 Nov 2010 10:13:17 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.59,191,1288594800"; d="scan'208";a="219525246"
Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 13 Nov 2010 10:13:50 -0800
Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oADIDnXg010819; Sat, 13 Nov 2010 10:13:50 -0800 (PST)
Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 13 Nov 2010 18:13:49 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 13 Nov 2010 18:13:48 -0000
Message-ID: <5FDC413D5FA246468C200652D63E627A0B65D288@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <4CDE97D2.7010005@tlc.polito.it>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] Increasing the Initial Window - Notes
Thread-Index: AcuDOd6HpH373SHJQcmoIqQg+j7sBAAIwXqw
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><9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no><AANLkTinMKHVf_HAQ-YT8K-Tq9jdmpqQXdgnQyS8+gAcd@mail.gmail.com><FD7B10366AE3794AB1EC5DE97A93A37316BF44877D@EXMB01CMS.surrey.ac.uk><4CDD493B.6000201@tlc.polito.it><FD7B10366AE3794AB1EC5DE97A93A37316BF4314A0@EXMB01CMS.surrey.ac.uk><4CDD59BE.60704@tlc.polito.it><AANLkTimmPD6Q9fPJ5EKH+yQmOj9=ZkucNqAK7154KoMe@mail.gmail.com> <4CDE97D2.7010005@tlc.polito.it>
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Marco Mellia <mellia@tlc.polito.it>, Yuchung Cheng <ycheng@google.com>
X-OriginalArrivalTime: 13 Nov 2010 18:13:49.0770 (UTC) FILETIME=[855B2AA0:01CB835E]
Cc: tcpm@ietf.org, L.Wood@surrey.ac.uk
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: Sat, 13 Nov 2010 18:13:24 -0000

Marco,


Isn't then what you are really asking for  AQM at the basestation
downlink path?

Obviously, running FIFO queues there is no the brightest of ideas. With
any decent AQM, the impact to any one flow should be proportional to
it's consumed bandwidth. In the degenerate case of IW3 and IW10 initial
transmission burst and an overloaded downlink, shouldn't the basestation
queue drop 10/3 as many packets belonging to IW10 flows, than packets
belonging to IW3 flows, so that each flow is allowed an approximate fair
share of downlink capacity?

And it's been a long time that it's known that "any" AQM scheme will be
beneficial over FIFO tail-drop queuing...

Even then IW10 will be beneficial, as it is easier, and more
packet-conserving, for IW10 flow TCP to recovery that loss in a timely
and work-conserving fashinon...

IIRC, the recent data did contain data points showing the relative
effects of IW3 vs. IW10 vs. bulk transfers over a "shared" bottleneck
link - although only a very limited number of clients being busy at the
same time (4-6 flows in total).

Richard Scheffenegger
 

> -----Original Message-----
> From: Marco Mellia [mailto:mellia@tlc.polito.it] 
> Sent: Samstag, 13. November 2010 14:51
> To: Yuchung Cheng
> Cc: tcpm@ietf.org Extensions; L.Wood@surrey.ac.uk
> Subject: Re: [tcpm] Increasing the Initial Window - Notes
> 
> 
> 
> > Browsers open lots of connections these days and we always 
> try to cope 
> > that in all our experiments.
> >
> > live:
> > To get the best possible apple-to-apple comparison when comparing
> > IW10/IW3 performance on our live frontends, we split the client IPs 
> > into two (same size) pools to serve IW10 and IW3 simultaneously. To 
> > our own surprise, mobile hosts are among the big winners 
> (even their 
> > browsers still open >2 streams per domain).  See slide 19 
> in our IETF
> > 77 presentation
> 
> Not surprised at all... since mobile terminal suffer higher 
> RTT, it is quite straight forward to see larger benefit there.
> The point is that you cannot see the impairment of other traffic...
> It it easy to gain 20% when 20% of flows goes IW10.
> 
> But what about the other 80% flows that were still using IW3? 
> Was there any impairment for them?
> Easy answer: if there is no congestion and there is enough 
> buffer space at the bottleneck link, then no impairment is expected.
> But if there is already some congestion, and then the 
> bottleneck queue is already overloaded, then I expect  lot of 
> impairment (and unfairness).
> 
> And what would be the gain if 100% of flows goes IW10?
> 
> Are the benefit larger than impairments? Then go for IW10, or 
> even IW16.
> 
> Those are questions that your data cannot answer I would say.
> Has someone run at least some simulations to see what can 
> happen on a congested path?
> 
> Ciao
> Marco
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>