From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4343921F984 for ; Mon, 3 Aug 2015 20:20:57 -0700 (PDT) Received: from block9.public.monkeybrains.net ([162.217.75.161] helo=[192.168.128.6]) by masada.superduper.net with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZMSmc-0004rI-R3 for make-wifi-fast@lists.bufferbloat.net; Tue, 04 Aug 2015 04:20:56 +0100 Message-ID: <55C02F97.2090601@superduper.net> Date: Mon, 03 Aug 2015 20:20:55 -0700 From: Simon Barber User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: make-wifi-fast@lists.bufferbloat.net References: <356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com> <5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de> <4D24A497-5784-493D-B409-F704804326A7@gmx.de> <1438361254.45977158@apps.rackspace.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070707040401040604020102" X-Spam-Score: -2.9 (--) Subject: Re: [Make-wifi-fast] [Cerowrt-devel] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 03:21:26 -0000 This is a multi-part message in MIME format. --------------070707040401040604020102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Indeed - to get maximum performance with WiFi you must form large aggregates. They are limited to 5.3ms of data, which is a theoretical 4MBytes of data for 11ac radios. (8x8, MCS9). In practice, today it's very rare to see > 3x3 and MCS8 or 9, so somewhere between 1.5 and 2MBytes of data in an aggregate. You need sufficient queues to form these aggregates, or performance is very poor. Simon On 7/31/2015 10:04 AM, Jonathan Morton wrote: > > > I think that is achievable, *even if there is a WiFi network in the > middle*, by thinking about the fact that the shared airwaves in a WiFi > network behaves like a single link, so all the queues on individual > stations are really *one queue*, and that the optimal behavior of that > link will be achieved if there is at most one packet queued at a time. > > I agree that queues should be kept short in general. However I don't > think single packet queues are achievable in the general case. > > The general case includes Wi-Fi networks, whose TXOP overhead is so > ruinously heavy that sending single MTU sized packets is inefficient. > Aggregating multiple packets into one TXOP requires those several > packets to be present in the buffer at that moment. > > The general case includes links which vary in throughput frequently, > perhaps on shorter timescales than an RTT, so either packets must be > buffered or capacity is left unused. This also happens to include > Wi-Fi, but could easily include a standard wired link whose competing > load varies. > > The endpoints do not have and do not receive sufficient information in > sufficient time to reliably make packets arrive at nodes just in time > to be transmitted. Not even with ECN, not even with the wet dreams of > the DCTCP folks, and not even with ELR (though ELR should be able to > make it happen under steady conditions, there are still transient > conditions in the general case). > > - Jonathan Morton > > > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --------------070707040401040604020102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Indeed - to get maximum performance with WiFi you must form large aggregates. They are limited to 5.3ms of data, which is a theoretical 4MBytes of data for 11ac radios. (8x8, MCS9). In practice, today it's very rare to see > 3x3 and MCS8 or 9, so somewhere between 1.5 and 2MBytes of data in an aggregate. You need sufficient queues to form these aggregates, or performance is very poor.

Simon

On 7/31/2015 10:04 AM, Jonathan Morton wrote:

> I think that is achievable, *even if there is a WiFi network in the middle*, by thinking about the fact that the shared airwaves in a WiFi network behaves like a single link, so all the queues on individual stations are really *one queue*, and that the optimal behavior of that link will be achieved if there is at most one packet queued at a time.

I agree that queues should be kept short in general. However I don't think single packet queues are achievable in the general case.

The general case includes Wi-Fi networks, whose TXOP overhead is so ruinously heavy that sending single MTU sized packets is inefficient. Aggregating multiple packets into one TXOP requires those several packets to be present in the buffer at that moment.

The general case includes links which vary in throughput frequently, perhaps on shorter timescales than an RTT, so either packets must be buffered or capacity is left unused. This also happens to include Wi-Fi, but could easily include a standard wired link whose competing load varies.

The endpoints do not have and do not receive sufficient information in sufficient time to reliably make packets arrive at nodes just in time to be transmitted. Not even with ECN, not even with the wet dreams of the DCTCP folks, and not even with ELR (though ELR should be able to make it happen under steady conditions, there are still transient conditions in the general case).

- Jonathan Morton



_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wifi-fast

--------------070707040401040604020102--