[Cake] ieee vs ietf stds for dscp mappings

[Sebastian Moeller]

Hi Toke,

On Nov 15, 2015, at 15:52 , Toke Høiland-Jørgensen <toke at toke.dk> wrote:

> Sebastian Moeller <moeller0 at gmx.de> writes:
> 
>> 	On the wifi-side my limited understanding of the access rules tell me,
>> that allowing clients to pick their qos marking can and will starve the AP of
>> TxOps, so unless the AP can enforce a unified tier for all clients the AP
>> should, in my humble opinion, actually pick its own marking (and medium access
>> probability) adaptively, depending on what the clients use, in a nice BE
>> environment stick to BE but if the clients start sending too many packets in the
>> two higher classes (dynamically measured threshold might be required) the AP
>> should up its game and switch its own packets to the same class. My rationale is
>> that the AP is going to have a better vantage point of the competing clients and
>> hence should be in a better position to guarantee some sort of fairness, than
>> any one client. Since this seems so simple, there probably is a very good
>> technical reason why this can not work, that I am just unable to see.
> 
> The problem with WiFi is that there are actually two effects of QoS:
> There's the priority queueing (i.e. the four 802.11e queues work as
> strict priority queues), and there's the retransmission and back-off
> behaviour associated with each of the tiers.

	Sure, not necessarily the best design, conflating two nominally orthogonal dimensions, no?

> 
> The latter is what can cause starvation for other clients: Because
> the transmission and back-off settings for the "latency-sensitive"
> queues (VO and VI) are more aggressive, they will tend to starve out
> other things.

	Yes, rrul tests between my macbook and my wndr3700v2 show this starvation issue nicely, the AP only gets the occasional TxOP… 

> However, it's not guaranteed that the AP can detect that
> this is happening (it would just see a lot of collisions).

	How not, in a non-ad-hoc network the AP should be able to see all packets, no? (Okay maybe not packets from other APs, is the wifi header encrypted?)

> You could try
> to infer it by looking at the markings of the packets,

	Yes, in its own network an AP (at least its wifi driver) should see the marking of all packets and hence should be able to tally them, I believe.

> but in principle
> there's no reason why a client can't use more aggressive transmission
> settings for packets that are not diffserv marked at the IP layer.

	Sure, but since (currently) wifi is half-duplex, that more aggressive transmission by one client is going to bring down the cumulative bandwidth for all connected clients. So I see this ripe for gaming, the one aggressive client gets a much larger share of a reduced bandwidth pool while everyone else is going to suffer, including the AP. Under the assumption that the AP is going to be the arbiter in the wireless network (due to its vantage point) I beleve the AP needs to compete aggressively for TxOPs itself, otherwise all fairness/control is lost. Now, if one controls all clients and one is certain that no client is going to game the system, the AP can stay “passive”, but that is a classic example for differences between cooperative and preemptive “multitasking/resource-sharing” the first works better in the good cases but is easily gamed by noncooperative behavior of individual “players” while the second sacrifices some best case performance” for a much better defined worst-case performance (at least that is my layman’s understanding of the trade-offs between the two).
	In the wifi case , I might add the co-operation approach is hindered by the fact that several APs / wireless networks might share the same frequency and hence TxOPs… As always, most likely I am missing relevant knowhow to realize the obvious ;)


Best Regards
	Sebastian
> 
> -Toke