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 A8C1821F44C for ; Sun, 9 Aug 2015 13:27:24 -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 1ZOXBf-0002Wv-JJ for make-wifi-fast@lists.bufferbloat.net; Sun, 09 Aug 2015 21:27:21 +0100 Message-ID: <55C7B7A9.4070708@superduper.net> Date: Sun, 09 Aug 2015 13:27:21 -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> <6E08E48D-5D53-48E5-B088-2D1DB5E566AD@gmail.com> <1438983998.16576420@apps.rackspace.com> <1439066765.7348311@apps.rackspace.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060207090803020704030609" 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: Sun, 09 Aug 2015 20:27:53 -0000 This is a multi-part message in MIME format. --------------060207090803020704030609 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 11ac with it's always on RTS/CTS and mandatory A-MPDUs really performs much better than many 11n implementations. It's finally a fairly sane MAC. The 64 bit limit in the compressed block ack is a limiter though. The really wide channels are another complex area for busy networks. The aggregation overhead for 11ac is about 222uS, counting EDCA backoff, RTS, CTS, PLCP header and the Block-ACK and all the inter frame spaces. One full size ethernet frame at 1Gb/s = ~12us. Large aggregates are critical to good efficiency and performance, and a certain amount of queuing is required to form them. They have to be completely formed before transmission starts. Simon On 8/9/2015 12:31 PM, Jonathan Morton wrote: > > The question of whether to aggregate under congested conditions is > controversial, probably because it depends on complex conditions. > There are arguments both for and against. > > It may be worth considering it as a risk/reward tradeoff. Given N > packets (which for brevity I'll assume are equal MTU sized), the > reward is obviously proportional to N. Risk however is calculated as > probability * consequence. > > Assuming all packets in the aggregate are lost on collision, the risk > of collision scales with L*N, where L is N plus the overhead of the > TXOP. Under that argument, usually you should not aggregate if the > probability of collision is high. > > However, if only one packet is lost due to collision with, for > example, a small RTS probe which is not answered, the risk scales with > L, which is sublinear compared to the reward relative to the amount of > aggregation (especially at high data rates where the TXOP overhead is > substantial). Under this assumption, aggregation is usually > profitable even with a high collision probability, and results in > overall higher efficiency whether or not collisions are likely. > > This is the difference between the typical 802.11n situation (one > checksum per aggregate) and the mandatory 802.11ac capability of a > checksum per packet. As long as you also employ RTS/CTS when > appropriate, the possibility of collisions is no longer a reason to > avoid aggregating. > > - Jonathan Morton > > > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --------------060207090803020704030609 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 11ac with it's always on RTS/CTS and mandatory A-MPDUs really performs much better than many 11n implementations. It's finally a fairly sane MAC. The 64 bit limit in the compressed block ack is a limiter though. The really wide channels are another complex area for busy networks.

The aggregation overhead for 11ac is about 222uS, counting EDCA backoff, RTS, CTS, PLCP header and the Block-ACK and all the inter frame spaces. One full size ethernet frame at 1Gb/s = ~12us. Large aggregates are critical to good efficiency and performance, and a certain amount of queuing is required to form them. They have to be completely formed before transmission starts.

Simon

On 8/9/2015 12:31 PM, Jonathan Morton wrote:

The question of whether to aggregate under congested conditions is controversial, probably because it depends on complex conditions.  There are arguments both for and against.

It may be worth considering it as a risk/reward tradeoff.  Given N packets (which for brevity I'll assume are equal MTU sized), the reward is obviously proportional to N.  Risk however is calculated as probability * consequence.

Assuming all packets in the aggregate are lost on collision, the risk of collision scales with L*N, where L is N plus the overhead of the TXOP.  Under that argument, usually you should not aggregate if the probability of collision is high.

However, if only one packet is lost due to collision with, for example, a small RTS probe which is not answered, the risk scales with L, which is sublinear compared to the reward relative to the amount of aggregation (especially at high data rates where the TXOP overhead is substantial).  Under this assumption, aggregation is usually profitable even with a high collision probability, and results in overall higher efficiency whether or not collisions are likely.

This is the difference between the typical 802.11n situation (one checksum per aggregate) and the mandatory 802.11ac capability of a checksum per packet.  As long as you also employ RTS/CTS when appropriate, the possibility of collisions is no longer a reason to avoid aggregating.

- Jonathan Morton



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

--------------060207090803020704030609--