From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 354853B29E; Fri, 17 Feb 2017 04:52:40 -0500 (EST) Received: from mail.toke.dk (localhost.localdomain [127.0.0.1]) by mail.toke.dk (Postfix) with ESMTPS id B2C32747BB; Fri, 17 Feb 2017 10:52:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1487325158; bh=ERFfx7Jl5l+ERBS65mtv6lLJykEYgOyJN5Ujbx+Omg4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=XL38opeIxJ9GPfhkaLXAFVSBFQKVuY8+Ej0Htd97Eef3qiNJGfCXk/RGRQ2lDyJd7 AMTTy5w6gCUEc9uProTA8t0wYW7gTGbG9PsfUGlNm35ltuFek0l5tpOh443BImeZjI /S11BnESekFz1OAskS52MMjG8sLUhy32UmNBNyseYm+W9UZwjxhyiQE3VYZ0Getg85 I7AZXgylSsqqSeNn6QBOT2ihJChC7l/Dmn1odFDAMxCuQSs4+cYqNfC9+LLBv9rHeP QXRTVgiIsiYuI03ervmf2Hz2FCp7TzksD05kNvAZMqNsE6gw2bMNZaN2aGEfdOSfud VEb+X2vjeuRvg== Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 94638A580B9; Fri, 17 Feb 2017 10:52:38 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Pete Heist Cc: Sebastian Moeller , cake@lists.bufferbloat.net, Aaron Wood , make-wifi-fast@lists.bufferbloat.net References: <32C42951-373F-4D90-8936-AA07039E5D73@gmail.com> <877f5c2pew.fsf@toke.dk> <42AC44CD-8C22-4EBC-B6AB-7786BA505D07@gmail.com> <35E83BE1-73D8-4FF9-B2E8-A49073E67EBA@gmail.com> <83F97E77-3CCD-44B2-B9EB-7F34DA3A3A50@gmail.com> <09A27886-7088-4493-A262-3CC2FF4C6CE2@gmail.com> Date: Fri, 17 Feb 2017 10:52:38 +0100 In-Reply-To: <09A27886-7088-4493-A262-3CC2FF4C6CE2@gmail.com> (Pete Heist's message of "Fri, 17 Feb 2017 08:53:19 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8737fd5el5.fsf@alrua-karlstad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [Cake] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 09:52:45 -0000 Pete Heist writes: > On Feb 16, 2017, at 10:03 PM, Sebastian Moeller wrote: > > On Feb 16, 2017, at 18:19, Jonathan Morton wrote: > > In a sense if there are thresholds for permissible VO/VI traffic fractio= ns below which the AP will not escalate its own priority this will come clo= se to throttling the high priority senders, no?=20 > > I thought Aaron=E2=80=99s suggestion sounds both sensible and not diffic= ult to implement. That way we wouldn=E2=80=99t even have to regularly monit= or it, and anyone who is marking all their packets thinking they=E2=80=99re= doing themselves a favor is just limiting their max throughput. > > Could there be another keyword in Cake to do this automatically, say =E2= =80=9Cfairdiffserv", or would this just be feature bloat for what is alread= y a sophisticated shaper? I don=E2=80=99t know if there are sensible mappin= gs from dscp value to max percentage throughput that would work most of > the time, or if there could also be an adjustable curve parameter that c= ontrols the percentage backoff as you go up dscp levels. > > This is actually what Cake already does by default (the =E2=80=9Cdiffser= v3=E2=80=9D mode). If you look at the detailed statistics (tc -s qdisc), y= ou=E2=80=99ll see that each tin has a =E2=80=9Cthreshold=E2=80=9D bandwidth= . If there=E2=80=99s more traffic than that threshold in that tin, the tin= will be deprioritised - it can still use all of the > bandwidth left spare by other tins=E2=80=99 traffic, but no more than th= at. > > Additionally, diffserv3 mode uses more aggressive AQM settings on the = =E2=80=9Cvoice=E2=80=9D tin than the =E2=80=9Cbest effort=E2=80=9D tin, on = the grounds that the former is a request for minimum latency. This should = also discourage bulk traffic from using unnecessarily high DSCPs. > > However, in both the =E2=80=9Cbesteffort=E2=80=9D and =E2=80=9Cdiffserv3= =E2=80=9D cases, the DSCP may be interpreted independently by the NIC as we= ll as Cake. In the case of wifi, this affects the medium grant latency and= priority. If the link isn=E2=80=99t saturated, this shouldn=E2=80=99t aff= ect Cake=E2=80=99s prioritisation strategy much if > at all, but it does have implications for the effect of other stations s= haring the frequency. > > Here is part of the problem: the more aggressive airtime access of the V= I and VO classes will massively cut down the actual achievable bandwidth ov= er all classes. And I might add this effect is not restricted to the AP and= station under one=E2=80=99s control, but all other stations and APs using > the same frequency that are in the close RF neighborhood will affect the= available airtime and hence achievable bandwidth. If you look how wifi ach= ieves its higher bandwidth it is by using longer periods of airtime to make= up for the rather fixed time =E2=80=9Cpreamble=E2=80=9D that wastes time w= ithout > transmission of user data. VI users in the vicinity will drastically (II= RC) reduce the ability to send those aggregates. In other words link satura= tion is partly a function of which AC classes are used and not a nice and f= ixed entity as for typical wired connections. Now if you can control both > sides of your transfer _and_ all other users of the same frequency that = are RF-visible to your endpoints, it might be possible to thnk of a wifi li= nk in similar terms as a wired one, but I would be cautious=E2=80=A6 > > Thanks for that info. In my testing I=E2=80=99m focusing on point-to-poin= t Wi-Fi, but I see the complexity that WMM presents, especially when there'= s more than one station. > > It's perplexing that at least two concerns- packet retransmission and pri= oritization, occur at multiple layers in the stack. 802.11 ack frames are s= ent in response to every data frame (aggregation aside), and retransmission= occurs at this layer, but also higher up in the TCP layer. Prioritization > can occur at the IP layer, but then again in the media layer with WMM. Th= is seems to violate separation of concerns, and makes it difficult to ascer= tain and control what=E2=80=99s going on in the system as a whole. > > It feels like WMM went a step too far. There may have been (may still be)= valid performance reasons for Wi-Fi to take on such concerns, but as the d= ata rates get higher and processing power increases, it feels like it would= be better to have a wireless technology that just delivers frames, > and to push reliability, prioritization and aggregation back up into the = higher layers so that long-term innovation can take place in software. The = 802.11 spec is on my reading list so I might learn if and where this goes o= ff the tracks. Note that WMM also affects max aggregation sizes; the VO queue doesn't do aggregation at all, for instance; and the max aggregate size for VI is smaller than for BE. This *should* be an incentive to not use the higher queues for bulk traffic. That being said, I do believe there are issues with how the QoS levels are currently handled in the Linux WiFi stack, and looking into that in more detail is on my list somewhere... :) -Toke