From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 983CA21F50D for ; Sun, 15 Nov 2015 13:40:21 -0800 (PST) Received: from hms-beagle.home.lan ([87.164.160.171]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MTSmp-1Zr6UM3PwF-00SQPU; Sun, 15 Nov 2015 22:40:13 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <20151115132023.317a0478@xeon-e3> Date: Sun, 15 Nov 2015 22:40:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93874204-46E0-4878-9F1E-021B68EB1325@gmail.com> <76A52374-F550-4DB6-9E11-91929794126B@gmx.de> <878u5zl3gn.fsf@alrua-karlstad.karlstad.toke.dk> <20151115132023.317a0478@xeon-e3> To: Stephen Hemminger X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:q+f0hluoJ0KRDhZQUkIAS18urXU5ZTOntEdEzW+JSkCGoQLaTXI 8D05lcKLRAb38pwY9oVsm5f7cHGqOn53wYWDy0fzijTGnNzjw/iLbR+ETFkVQC4pOoCKPPF eYsO7QsoJ7scbxz6+vTISpQpfM0Q/ayrvw9OQ9NagS3ekRlhHze3t6np5Szc3LCLBmqS9By /rCOOFtniSuqeK0lVg3uQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:m/nO5T4jkkY=:RaSzHefW0sdrhmb0SxJsBx zOoyUSfLQ4fnvDVsmzYto532svgAqahVMiztvHEn3PCAu93FzrvcZIp2tUijZ/iKhjB4nt68t wDlq3sApBqMzcFZUhO/mtLDN2GolIeoRP5YVeDug+L3TB1wnK8YOWJWrcRfHyz3HqF2LctyjR LGA+m40E8cdUJH4dRqtNurwBQBF3IGaf59w/rAADhx3VgsGzmqIte8/yu7dlgfQBz9RJdHRx9 Ko0bXW0DdgXlWilLFNVzs0jb7LVd6cIsqeewWcG8949CNDK+VZOD52T2WX4sKCoEgy4xEvqGV XOcN9okM9iOnfVHYytSLDo6eW3vvBXMELm2WeMCG726QHAfX4MadkhTqDyPyv5L/dPaHETjUn vbU6e2Das8iqB69CfW1yLHh/X993KMfwsVzcJjEROnrwgNRNhm2gSK7sf+TqNxvEfsliuUSM/ fw6D19T6DrhIcLlIVGSTE/6qxNb4vX//sV5HKtd4SzLHY4XvI7zehKU50/WvhEn9RAhAIRBIq 8LtV63a7PTrzI8WYg1TYnIWmP7W+o/QjuEOnnz+LT24nKvWz2u64MYQXHevLaeI1rDFYHSROk GzHzFIXhFrTAyLo+4dWII8qtolGIzkGEMQ0xKTIo9PkhVMeRoiFlk+uS4FgRYNivjCRNL728Y dKvCHIcOpluEvIcNQecUPp2ohJ7H/gKdl8ku790aqatILfvfzmnKWAmqn2bcjT3DBh6sZ3qsL LnlPrVI4fQZyRYqYNH6HRTEm9wrKacrMP2vebXh890DKmNeafDOtT+e3Nk5gwb4NdloYJ4x4g VPenl66 Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] ieee vs ietf stds for dscp mappings X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 21:40:44 -0000 Hello Stephen, On Nov 15, 2015, at 22:20 , Stephen Hemminger = wrote: > On Sun, 15 Nov 2015 15:52:40 +0100 > Toke H=F8iland-J=F8rgensen wrote: >=20 >> Sebastian Moeller writes: >>=20 >>> 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. =20 >>=20 >> 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. >>=20 >> 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. >=20 > 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=92s 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 =93all stations are hostile=94 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 =93competition=94 makes this a = better strategy.=20 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=