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

[David Lang]

On Sun, 9 Aug 2015, 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.

remember that there are stations out there that aren't going to hear your 
RTS/CTS, especially in dense layouts.

Just like wired networks benefit greatly from time-based queues rather than 
packet count based queues, I think that wifi aggregation should not be based on 
packet count (or even aggregate size) but rather the amont of airtime that's 
going to be used (aggregate size * bit rate + overhead)

If the AP can keep track of how many collions it's had/seen over the last X 
time, that can factor in as well. I agree that the 802.11ac ability to only 
loose a packet instead of the entire transmission is a big step forwards, 
unfortunantly there's not that much equipment out there yet that will take 
advantage of it. But it does mean that it's probably worth having two different 
algorithms for the -ac and non -ac endpoints.

Which makes it even more important that the queue logic get information about 
the particular endpoints when deciding what data should be transmitted next.

David Lang