From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4022121F719 for ; Sun, 9 Aug 2015 14:43:31 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t79LhUDM020390; Sun, 9 Aug 2015 14:43:30 -0700 Date: Sun, 9 Aug 2015 14:43:30 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Simon Barber In-Reply-To: <55C7B7A9.4070708@superduper.net> Message-ID: 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> <55C7B7A9.4070708@superduper.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============3281511431731421462==" Cc: make-wifi-fast@lists.bufferbloat.net 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 21:44:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============3281511431731421462== Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII On Sun, 9 Aug 2015, Simon Barber wrote: > 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. do you know the per-transmission overhead for different modes (n and a/g specifically)? Also, what parts of the overhead get extended when the data rate slows? It's all well and good to talk about a full size packet being 12us at 1GHz, but that requires a good signal an 3x3 radios. If instead you are on a 1x1 radio with not as good a signal, you can easily drop your data rate by an order of magnatude or so. At ~100Mb your data packet is now 120us, what is the overhead? if you drop to 10Mb your packet is now 1200us, what is the overhead. David Lang > 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 > > --===============3281511431731421462== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ Make-wifi-fast mailing list Make-wifi-fast@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/make-wifi-fast --===============3281511431731421462==--