From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 932DE3B29E; Sun, 31 May 2020 15:25:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590953139; bh=YRO4R67H2bQeOM4e4iw0SiReEoE/W9SsR5MkX87oleM=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=U5LLuqn2In2Rfl+I2hbSKvH47unQQ5yK8DxK518sO5Xgi26wr69lhzbVhyBg9DqMY BabTKhG8JQCmlbz64CObgL6rydhCFFVHJx/vtV+CGk5SNzY0KPr+U9KXe2ikhAh0oB eYSU5fzNz6eI/9DehgLdG3t3eOkuQZbkXplmmWXM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([77.10.116.28]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MHoRA-1jjNK92XBO-00Evnc; Sun, 31 May 2020 21:25:39 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 31 May 2020 21:25:38 +0200 Cc: Kevin Darbyshire-Bryant , Cake List , Make-Wifi-fast Content-Transfer-Encoding: quoted-printable Message-Id: <94C64962-BD1F-435E-9A16-802921184D02@gmx.de> References: <5136DAB5-B975-4D36-948D-A5A4167A8FC7@darbyshire-bryant.me.uk> <30B03A82-420A-4A9A-899B-8549692AF9DC@darbyshire-bryant.me.uk> <2BE61C3D-EED3-405A-A7AF-BA7B7B5B8B03@darbyshire-bryant.me.uk> <7D02924D-1B16-4274-8BBF-6CBAA59CBB59@darbyshire-bryant.me.uk> <74B276D6-8CF0-4B85-B241-D1330B801462@darbyshire-bryant.me.uk> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3445.104.14) X-Provags-ID: V03:K1:qcSnUs/r8MLVakseCrcjL9CGAJUFED33KY1GfS2ItFJhktoZQtq pzqolSeF38EkYiiJzsEgNzSMkiGM45FYaMI4LfLvDMxH7zIN4yHZA1482gGBwhphmzBuiuy enyXMLtlj2Nn7cmESQJDpv/KM9wH80SaRr9q8qGMHRn9vPzBIlpAk/i6RAFj0ypX6JNwJuO 1/5W2CGCGxg6O6HQfMQ7Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:gI3ziFju8VE=:fdp4WiYp1RaGOU9V4Mxd5b c/iyjxVEMbuhA8QDUbWNHs4zXC/g+xAatlPjQoG/Ma4x4ROLijJmNnB0lgGV9kkBFlAlkqQ8f +MHBfeOKj9lx72c3cXYw8TkOFJWin3toXK1e5sQlhtweBvDPjAkpUlQRJ0xRxED8xxeSnklbB RyvULaFEyYNdT5GK03jEABmo80XcqhxpK6089UH8kOIAvCSccwd7fMSt+dKya6hI1IGDnwzkw wbBlYY0FY3SZZancLmqA5olNjC70z1mVcykP801+ZBlow+7Mhayw/SkOpMHqmZfaibiILXcHN 6VFip/o73viLLehaqgWSrqUw4S/vDjXajqT+n5G2NBDnqDHkMRWUazIsNvqKVmNroRKozb56+ KUrj6rTmC3pwSWPidZ21gJ8Anc2UGt7akiuCLMu060VZHICqJJFlMKBMl7b2NfWuumNCllZDM RqWJsbpELCHl5DKRFv38gY/AC+ZyT3/gAQo0BEvMxb9xXwxB3kjnemBQox3+Xq+aLkNIEThBI /bAzPBKjji2YHp5uqxur7ustT/K26F3EBf6sEiOOEyZPC2VZa6cyhBlTHFpXihyuwqr1Nf3K7 gBnNWCYQk11DySu+QtZD4Da+UATLEyavbqN3vwiO5PHYmF6K+Xo4tSPO9HXuIOY6vQNc06Zn8 eluGKP2Elc3kEmr/1vKEZdsrPkWgC8uvvCXzHjuALI2Hn6PKSW2gRnmN9wVqwbuBCqq+7F/id opzm05FjYWD9CfUM8xAQ3qGodSI3JZ72LtqGk9DB0HZBENkwcIZAEoBVZI0VGWE34fiJHT/9w c1Y63JZPQ3zWDf71IoUQXeR1q2wrL2ik4fe6c1uLGhy95/LwoFufPD8/XFvxDkZSzLgrQbSzR B38oZ6pm72IcecJTFinI4VOCnll6yquQl2GZM/0EXg/wjPVPYJjmYSgL+OeBsoPpZfuW27xEH F4ORr5SKplqOQ/pgM0WyS7KAhokZRJTQvldGsm3frpv55NJqwqyaX2mma4tduh4nesMpcSQAJ p8pDIDclA9p/O8RUFn0nQA0NwEynoMGebI1YXdYIO74nnetaPXfTghAwsiiUgQUA8syyNSTD/ xuSjixCP+hWeVOZUazfJh5TkL4O7BqO4Oy7QRgb/GcRbik4zVImh6L5BcAldh9eNla2FvDluV DBxi09aBb9ubMJPZfKQFxlKcMMlghYGaug8m2XkJ/hS5u6MkfUwEUE0WjzF7W8TPHGGwUztk9 zLu6Pea+z7Mi21KmA Subject: Re: [Cake] Playing with ingredients = ruined the CAKE X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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, 31 May 2020 19:25:43 -0000 Hi Dave, > On May 31, 2020, at 21:01, Dave Taht wrote: >=20 > On Sun, May 31, 2020 at 11:08 AM Kevin Darbyshire-Bryant > wrote: >>=20 >>=20 >>=20 >>> On 31 May 2020, at 18:26, John Yates wrote: >>>=20 >>> On Sun, May 31, 2020 at 1:08 PM Kevin Darbyshire-Bryant >>> wrote: >>>> I have absolutely no idea, don=E2=80=99t appear to have that thread = :-) >>>=20 >>> Mea culpa. Should have included this link to the thread: >>>=20 >>> = https://lists.bufferbloat.net/pipermail/make-wifi-fast/2020-May/002860.htm= l >>>=20 >>> /john >>=20 >> Ah, well after the initial excitement that =E2=80=98oh an application = actually sets DSCP=E2=80=99 I checked what marking my zoom packets had = on the next conference=E2=80=A6to find=E2=80=A6 Best effort. Crushing = disappointment led to this in my firewall box: >>=20 >> #Zoom - connections go to Zoom with dest ports 8801-8810 >> $IPTABLES -t mangle -A QOS_MARK_F_${IFACE} -p udp -m udp -m set = --match-set Zoom4 dst -m multiport --dports 8801:8810 -j DSCP = --set-dscp-class CS3 -m comment --comment "Zoom CS3 VI" >> $IP6TABLES -t mangle -A QOS_MARK_F_${IFACE} -p udp -m udp -m set = --match-set Zoom6 dst -m multiport --dports 8801:8810 -j DSCP = --set-dscp-class CS3 -m comment --comment "Zoom CS3 VI=E2=80=9D >>=20 >> With dnsmasq configured to fill the Zoom4/6 ipsets with relevant IP = addresses >>=20 >> ipset=3D/zoom.us/Zoom4,Zoom6 >>=20 >> Works a treat. >=20 > groovy. nicer than what I did, except that I don't remember where CS3 > lands in wifi anymore! CS4 and CS5 land in the VI queue.... >=20 > As for the "EF" (and for that matter, CS6 and CS7) issue on wifi, it > lands in the VO queue. According to https://tools.ietf.org/html/rfc8325#page-10 it = actually often lands in AC_VI: "Voice (EF-101110) will be mapped to UP 5 (101), and treated in the Video Access Category (AC_VI) rather than the Voice Access Category (AC_VO), for which it is intended" Which IMHO is the right thing, AC_VO is so ruthless in acquiring airtime = when competing with the other AC's that IMHO it should only be kept as = the "nuclear option" in case an AP does not get sufficient airtime when = competing with AC_VO hogging stations, but not as part as a normal = scheme, UNLESS there are only managed APs in the environment, and any = airtime hogging is not at the expense of the neighbors... > babel and BGP sets CS6 last I looked, and the > VO queue on 802.11n (which is still quite common on both clients and > APs) cannot aggregate. Given the rise of videoconferencing, mapping > stuff into the VI queue makes the most sense for all forms of wifi, > for both voice and video traffic. I like to think we've conclusively > proven that > packet aggregation is way more efficient in terms of airtime and media > aquisition for both 802.11n and 802.11ac at this point. +1; not that I can back this up with data... >=20 > Worse than that, EF once meant "expedited forwarding", an early > attempt to create a paid-for "fast lane" on the internet. I'd not use > that > for anything nowadays. >=20 > So I could see EF landing in VI, and CS6, at least in the babel case, > being a good candidate for VI also, but the existing usage of CS6 for > BGP (tcp transfers) is a lousy place to put stuff into the VI queue, = also. >=20 > And all in all, our existing fq_codel for wifi code does not work well > when we saturate all four wifi queues in the first place, and in > general > I think it's better that APs just use the BE queue at all times with > our existing codebase for that. Someday, perhaps, the scheduler > will only feed 1-2 hw queues at a time.... +1, I would assume the issue is that queued packets in AC_VO = will basically stall all other quees until the VO queue clears. I have a = macbook, which in rrul_cs8 tests over wifi basically hogs all airtime = for its two AC_VO flows, essentially starving all other flows in both = directions to a trickle. Hence my assesssment that AC_VO is a tad = anti-social. >=20 > On the other hand, other APs, with massively overbuffered BE queues, > will probably do better with videoconferencing-style traffic landing > in VI, > so long as it's access controlled to a reasonable extent. >=20 > Clients SHOULD put videoconferencing (and gaming and latency sensitive > traffic, like interactive ssh and mosh) into the VI queue > to more minimize media acquization delays. >=20 > On the gripping hand, the best thing anyone can do for wifi is for all > devices to be located as close to the AP as possible. Puzzled, using zoom, over an ath9k radio with Toke & yours = airtime fairness/fq_codel fixes works quite well with competing traffic = even with zoom in the default AC_BE. May this is because my nominal = 100/40 link, shaped with layer_cake down to 49/36 Mbps does not make the = wifi into the real bottleneck in the first place... Best Regards Sebastian >=20 >>=20 >> Cheers, >>=20 >> Kevin D-B >>=20 >> gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A >>=20 >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >=20 >=20 >=20 > --=20 > "For a successful technology, reality must take precedence over public > relations, for Mother Nature cannot be fooled" - Richard Feynman >=20 > dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake