[Cake] ieee vs ietf stds for dscp mappings

[Sebastian Moeller]

Hello Stephen,

On Nov 15, 2015, at 22:20 , Stephen Hemminger <stephen at networkplumber.org> wrote:

> On Sun, 15 Nov 2015 15:52:40 +0100
> 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.
>> 
>> 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. However, it's not guaranteed that the AP can detect that
>> this is happening (it would just see a lot of collisions). You could try
>> to infer it by looking at the markings of the packets, 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.
> 
> In my experience with customers, they tend to put in hard
> policing limits for any of the latency sensitive queues. I.e if the network
> is 100mbit, they put in a policer to drop traffic over some limit (typically 25%
> of the bandwidth). That way they are guaranteed to not stave regular classes.

	Thank you very much for that information. How does this work, in a hem network environment in a dense neighborhood? In my home network I invite/allow my friend’s machines in, over which I have no control; also since wifi uses a shared medium and there are several APs around using the same 2.4GHz channels (there is like three competing APs in each of the useable bands, 1, 6, and 13, 5GHz is better though), I have no handle on what bandwidth is going to be available for me, nor how much of that bandwidth is used by others. (Also one of my SSIDs is open and unencrypted, something I would like more people to offer, but that ensures that I basically can nt trust even machines the are connected to my AP to behave friendly, so “all stations are hostile” is my default MO.)
 	I guess the point I am arguing is not that this can not be made to work in a controlled environment, but rather that most/many real world networks do not operate in a controlled environment, so I wold not be unhappy if my AP played temporally averaged tit-for-tat: start nicely as BE but escalate to VO or VI if the “competition” makes this a better strategy. 
	I have seen myself that one machine using VI and VO markings can make all machines on the same AP  pay a severe bandwidth and latency price (including the APs traffic to the stations, damn half-dplexicity). I can live well with the decreased bandwidth , but I dislike the increased latency ;) So I believe an AP with an adaptive strategy will work better (for my definition f good obviously). Since I do this as a hobby there is a more than decent chance that I am just missing the obvious, thinking myself way more knowledgeable about the issue at hand than I am.

Best Regards
	Sebastian