From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3068021F51E for ; Sun, 15 Nov 2015 06:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1447599161; bh=02pUdYJ3FzeIl0vxHOKmG9mkVNfY5DU4ZJDC5hmkGSg=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=XDWkRbGggVmwYFtIyvERn1waiM/eO5jfzOng7UEh4WB/GNuiobswJ0NQCRNh8fJiT tx3NDR88P2mrZltSzk4A1Fhkj3u8GiIblCP7tSmA3HpgudhY9Tv2jbtK7+S8vHGnZ0 ezAgWoSnqNZC2EQxuY7HjbkOhLGXdeXdkPQmoQWg= Sender: toke@toke.dk Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 0317B512A69; Sun, 15 Nov 2015 15:52:40 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Moeller References: <93874204-46E0-4878-9F1E-021B68EB1325@gmail.com> <76A52374-F550-4DB6-9E11-91929794126B@gmx.de> Date: Sun, 15 Nov 2015 15:52:40 +0100 In-Reply-To: <76A52374-F550-4DB6-9E11-91929794126B@gmx.de> (Sebastian Moeller's message of "Sat, 14 Nov 2015 16:53:46 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878u5zl3gn.fsf@alrua-karlstad.karlstad.toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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 14:53:08 -0000 Sebastian Moeller 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. -Toke