[Make-wifi-fast] [Cerowrt-devel] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e

[David Lang]

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 at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
-------------- next part --------------
_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wifi-fast