From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 A1BA621F553 for ; Sun, 15 Nov 2015 07:40:34 -0800 (PST) Received: from hms-beagle.home.lan ([87.164.160.171]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LoaCE-1aZp3P3HpK-00gUqN; Sun, 15 Nov 2015 16:35:25 +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: <878u5zl3gn.fsf@alrua-karlstad.karlstad.toke.dk> Date: Sun, 15 Nov 2015 16:35:41 +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> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:NEZw65r1WuNQmNagwsm55NcvrN3CWCzXRYJ+NiJct1fPAwnx9dx BCz4HmS7KmUjup03uEA86n0iGgDWJzXc8SFHCEkgsBrNEdHPK7BzmuoAEmj/w2fumQIYaTL LGWHejBsIC0hSyzWl5kGtowZxga0pUnitFG3Z/9EF+ElV7FeGkf2TAwMyedvcqvdMcE+16o Mkj4NEVS7ejorJrlqcQGA== X-UI-Out-Filterresults: notjunk:1;V01:K0:kcjGB+AMHm8=:Ypbu20kPC+ML3WFcHBsm5D q4fVFoQJFVl6Q4tP4glFw4wHUPkdSzWU6qflwHxGlPTbxYSlOTSjbdA+RF1024huWt7EwczAi 6k2dagQgZ577xTu3i+hAKFZycodev9bUl+sonQc20B0rmmelAwrJgGTRUdCIyVONAxxfpaslB rh4jOUn7ho0ZPD389JTwjY8u/1uaEpOvYhp03lLJQXivER8GaZ+BNWV4IlBRA47vR6TReBmUg 2Ad24xvfb35wU7zlYXJaglPSHVr93B+QcIToMUNWvN18M7NIyKluM+GK5mtl9RbbSw13w1B1L bhOswZB22DhlRBBtuu6tKV/Nru/GRGDZdRAVRXxTqFPlH6ZgDdDs8bEtQDg/+SG5jyea4C/c1 5R5kDMyfZWqWM3k0+mHtC/SwzdxHWfx61e/zeaULepDzu/5vng5F/617LYMl1ERZ5s0jyvSS9 j3luVh6pG2+dVyG8gt32y6RzOP+ODGMo+S9EfL25plBf6FICm6Md+HHeoxPjDHfB5CSPy7hJU Z2yct4ChsjZuEK35HigdWy+vHFoZLgU+8zQSoGRLAvaBX5Km/BavM4guMEaOrtsnlUOrvkTEC IheXypMJ+sy6sjzQhAXi3dcU2QDBF5hnAKwN47jzkf5JEAJRfbbnekSQnC0YUCQoYXQfRWxgp X8gQ4ZtHcDLsM44afMQkYJxD4xkiXGzyqskqZIVmniLULPSXwlHLg//Siqry7cpqSblMrmpa+ 9hJR88LuNk3PGIz/mLkNAcW6G6jL9xVSPD+NeL+BsKLepO7hpyPuM/5Sl5LVx1ydCO/HIzaNV kMEY98f 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 15:40:58 -0000 Hi Toke, On Nov 15, 2015, at 15:52 , Toke H=F8iland-J=F8rgensen = wrote: > 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 > 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? >=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. Yes, rrul tests between my macbook and my wndr3700v2 show this = starvation issue nicely, the AP only gets the occasional TxOP=85=20 > 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 =93passive=94, but that is = a classic example for differences between cooperative and preemptive = =93multitasking/resource-sharing=94 the first works better in the good = cases but is easily gamed by noncooperative behavior of individual = =93players=94 while the second sacrifices some best case performance=94 = for a much better defined worst-case performance (at least that is my = layman=92s 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=85 As always, most likely I am = missing relevant knowhow to realize the obvious ;) Best Regards Sebastian >=20 > -Toke