From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CA91221F50D for ; Sun, 15 Nov 2015 13:20:12 -0800 (PST) Received: by pacdm15 with SMTP id dm15so152660146pac.3 for ; Sun, 15 Nov 2015 13:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber_org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=GGBkpdwjGsr4BkXbnaSySmx69hqgNKhnGatxvT9NI+c=; b=r/fY9dAvFLCSat942u4VNMwupnTukBP9r6TVXNe0cI45AybDe0fmHuKjYUdCF6WORp VKmwmb+MirWPlRjSS+TXSJOZwkSVtvRYeC13VlCNRbFamL4VYMU1PeWdKbAesYqb1O50 EzHld1jb95y3Sz41WKdNKxT8ZkInRdZjaMkPHbRmS/pICuDlIHsh6RZ5V0lBp8oLv8rv UsQtyNTlqeqep2jUeUgwV7HeqR96LF/kYdUhKmks2drDVO2WyC5m2oSSt3d1nFI0dg8M MCLNbLvTyCcb3lnDDdoi+r7DsvQZGFBojUmZlfRveKLcpa7und2DxOv3wLooy2vjSS7i UhUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=GGBkpdwjGsr4BkXbnaSySmx69hqgNKhnGatxvT9NI+c=; b=Sc41R1osgx+Fe6jQHAWx1V3izLfPJk/zu36+WejZy3B93xPRtasRnoJTUX/kVOFbJY P8oRfz1YiFQczpY/iXN38PX/18+85mRALxKWFB6fVZMsp1/A7TcZlu9Z3GlDgmB07h3M L1bi3Gvy6IaDnmI+bJN1Map26tzZEdQyurMPrilJkt2mKHutfV234egkib/7C5kYJQJ1 h07Nhem7M7h86TeplpysvwrlGbkfzc2hNep4yrZtGlUMRhHsIqv+XRbS+h7f+wAFEmJD sMxUg2co9PySjz5Mjn6GQZBZJbkNgDElCVYEiIeXWN4hGfaXVfGHKI+XCTAEX+sui2yp hldA== X-Gm-Message-State: ALoCoQk7ePOtdWLrOR7FLtgSoSK2WAQaZ+t/8JMBvHnJUwcS3hyFwly2UgNhotCiXI3RdIQ8lGOJ X-Received: by 10.68.135.132 with SMTP id ps4mr48924479pbb.111.1447622411369; Sun, 15 Nov 2015 13:20:11 -0800 (PST) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id yg2sm32103386pbb.79.2015.11.15.13.20.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2015 13:20:11 -0800 (PST) Date: Sun, 15 Nov 2015 13:20:23 -0800 From: Stephen Hemminger To: Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= Message-ID: <20151115132023.317a0478@xeon-e3> In-Reply-To: <878u5zl3gn.fsf@alrua-karlstad.karlstad.toke.dk> References: <93874204-46E0-4878-9F1E-021B68EB1325@gmail.com> <76A52374-F550-4DB6-9E11-91929794126B@gmx.de> <878u5zl3gn.fsf@alrua-karlstad.karlstad.toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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:20:35 -0000 On Sun, 15 Nov 2015 15:52:40 +0100 Toke H=C3=B8iland-J=C3=B8rgensen 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 packe= ts in the > > two higher classes (dynamically measured threshold might be required) t= he AP > > should up its game and switch its own packets to the same class. My rat= ionale is > > that the AP is going to have a better vantage point of the competing cl= ients 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 go= od > > 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. 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 (typicall= y 25% of the bandwidth). That way they are guaranteed to not stave regular classe= s.