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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 768133B29E; Thu, 16 Feb 2017 16:03:08 -0500 (EST) Received: from [192.168.1.222] ([80.135.68.123]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LdpZX-1bwMlH2cCp-00izoJ; Thu, 16 Feb 2017 22:03:04 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Sebastian Moeller In-Reply-To: <83F97E77-3CCD-44B2-B9EB-7F34DA3A3A50@gmail.com> Date: Thu, 16 Feb 2017 22:03:03 +0100 Cc: Pete Heist , Aaron Wood , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Jonathan Morton X-Mailer: Apple Mail (2.3259) X-Provags-ID: V03:K0:UhM93xP8zOzXCAUsiZh86JjqDFJEHJULc2ItNiVu2SYcwe5crH1 uuYuewduBtS8NglnVfAGmU7yOVfNRzc66BUzfDw54OieptQO6vUR7ZtAMj3IcybJVfIot4X Ogzk1AshdYybmneMjEZEkSZ/kA/U7u10Gl5PYoz+QbXTWUUpi9Q3FP/jsobmEuPqqnxf2tB IMzNtU5PgGhA+pN6dNrbQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:aFEUjbW4pyo=:gSW2uC2DICDYTjS4IaZtGa Z2+XWezgpEgq5OSWWAILNVAhbkMWyXW2GUdgBrd4zFa3Pi9neLgM2x9jQS8lyrSzrdhvOWdcP LAbt9+Sfy0fvV6jPn4khIcpB/QWDUtZP2swn2K+noS6bhxbO7M/zxzqcuU2N+gMmes6ZeF9Qy 2B/T7yS38YYK1dal+Vixg7XdFOJHoN09no4mvcFwHRNpqIl3jHPtbOIp4j7kwgbHC4CUa1vhQ W5j1jOTRACgHAH7SAS5/0LW63dvDlKKSLQ6YLYEbLLGlGaKf1x49FD3Mt3PpgsnUeqrRQZzOO br0HQ+n4yi9bWQqrpZd6On1Zjmx2/OwgdIQRxecafjj4nW3b2KeJWLewt6qbSHeF26B0w2jhb ZKwhH2BKAuvcmiklwWxEAlNn8iY4Nv5aMHiAERbPQj+5ijbas8TBTvbLcNHi0vsryuXc0HTBH ADzOKHa5EjzCTygDHUVinF6/AN9V+L0n8FjFCD2sv8J6D90zW4CnJ7wR2Ja1Qu/HFW6v8cIK2 d5hBZSyR5ygUxt90ygBd93X96tytPdR4QgQwP6gtPH2fBrPf8+yGe3bMoRFpV65xLFsYdANVn klT40WSp9qJhIhnHSSLysoHl/6PFWc9wMIqd00/D1R/1Bf/elzSC+NBK3+4+j+Q6NLG/SeqcL K05jOnfDEKYOWOzClq1QW2a1BBgL3bCYH7G+AVqq2OBkGF26Brcs80mknJw4AANfPKrb6WHV4 C/I0fmrzN4lO8izyNmLZ8IMghb34PM3U/CSiu+qPVpdcTzaeAqYBocstNGo0R9yeY29eb2LwO rNNpPgNJOLzQGe6QvaJc+T7Ot77zC1Dkd2AYRgWoBsP+0l09qZrrXRDDLf0HzcAeiHs+Lz1HD SLSjQboj0nv8mJ6f4Xy8yFBBHmWlREicmCmbQpHNvqMvLRWuxqz/eCQ7fXMn526KyXG56lJyz qP2rte6BfeIfofHd4rBVIgz2EtEGnm6uSkfsGZWLY33SUInpTJM6tEkTnrBJ4cOnhboU+YTVy e2ejAca2/1JfjgEMfXTCsUfGs4BFaFXuEMU60ap/5i2dZABe/nCMU1QEU8O/R1ivHQ== 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: Thu, 16 Feb 2017 21:03:08 -0000 > On Feb 16, 2017, at 18:19, Jonathan Morton = wrote: >=20 >=20 >> On 16 Feb, 2017, at 18:51, Pete Heist wrote: >>=20 >> At first I was thinking to just remove diffserv markings entirely, = say with Cake=E2=80=99s besteffort flag, but I think that =E2=80=9Cgood=E2= =80=9D and =E2=80=9Cotherwise unknowing=E2=80=9D users would suffer, = which I think in FreeNet is a vast majority of users. >=20 > That=E2=80=99s not what the =E2=80=9Cbesteffort=E2=80=9D flag does. = It ignores DSCPs and puts all traffic into a single tin, but doesn=E2=80=99= t remove the DSCP marking. >=20 >>> In a sense if there are thresholds for permissible VO/VI traffic = fractions below which the AP will not escalate its own priority this = will come close to throttling the high priority senders, no?=20 >>=20 >> I thought Aaron=E2=80=99s suggestion sounds both sensible and not = difficult to implement. That way we wouldn=E2=80=99t even have to = regularly monitor it, and anyone who is marking all their packets = thinking they=E2=80=99re doing themselves a favor is just limiting their = max throughput. >>=20 >> 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 = already a sophisticated shaper? I don=E2=80=99t know if there are = sensible mappings 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 controls the percentage backoff as you go up dscp = levels. >=20 > This is actually what Cake already does by default (the = =E2=80=9Cdiffserv3=E2=80=9D mode). If you look at the detailed = statistics (tc -s qdisc), you=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 that. >=20 > 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. >=20 > 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 = well 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 affect Cake=E2=80=99s prioritisation strategy much if = at all, but it does have implications for the effect of other stations = sharing the frequency. Here is part of the problem: the more aggressive airtime access = of the VI and VO classes will massively cut down the actual achievable = bandwidth over 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 achieves 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 without transmission of user = data. VI users in the vicinity will drastically (IIRC) reduce the = ability to send those aggregates. In other words link saturation is = partly a function of which AC classes are used and not a nice and fixed = 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 = link in similar terms as a wired one, but I would be cautious=E2=80=A6 Best Regards Sebastian >=20 > - Jonathan Morton >=20