From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 AB4483B2A4 for ; Sun, 9 Jan 2022 17:51:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1641768684; bh=qAYEaZ8hQkV0hdNRhq1kve6vZt0M9trVA5Rtfp6jNhg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=OuPQGQI1Nvmq5B8EsJnmyCDXzyXLXKZfV8CdyAVNswUtLIxS6guDRfzd3auINrQHc jegTif+uMT5pVukkiz3UdGTLBkwiB2pAD0OhyFY0EYM7K8LaaPtkChLFWW/7w4zd7b /av5C925FfUu9lL1oJa5I6HxXnrQHs70nPm/9Z9U= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([77.0.196.3]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MbAci-1mVRP22m3U-00bcZO; Sun, 09 Jan 2022 23:51:24 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 9 Jan 2022 23:51:23 +0100 Cc: Aaron Wood , Make-Wifi-fast , Jon Pike Content-Transfer-Encoding: quoted-printable Message-Id: <9AA34825-7B78-4358-AF24-F559D109D5CF@gmx.de> References: <87r19nb27v.fsf@toke.dk> <87k0febdaq.fsf@toke.dk> <6F6FB992-807F-4F3A-9E46-D6C1B9CBE33D@gmx.de> To: Bob McMahon X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Provags-ID: V03:K1:C6f3Pk/ucg7dlmJPCrL+jr3doDbKvsMyPzxyBIkQyihfLqauUsX 8WiuDLZfg/rjPa+4bXGyx0ZJt457rh4k0NOytJs+liLOU8bwj9ya+HiViY6/qtj+hNxYHde UX7m3UFN5J0x+YPsRCEicNPCa/dgmkuzLRMu0S7DzZhXZgV5yF/yW3YxYDQvrQ1bd334l+s Cu6Hr2PkRKPG1u60zPQPA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:KBMqq/TmwN4=:Cj5OTzMSbO8OZ2vcy/wuHE Jp82UlpMuYD0m0FijvvOljmM49kYc82RBkWtPYgzIrECv/7XGLd3qb7p+DZVDC1lEdHnkDvFZ sfqIwGQGhGQ01/bqpZpM2CfAqPte1vDkIPcoQ5nEeCSF76//8n3m3IAi55z4QVOGkKiqu17w+ 8f1JUhzgiz9TVzcntRALlv84Wii42nIcKVyeTdM7Ze0w6MeJKh5bs9RpTYFLxI+RUbs2yZ1Zw LiQl/v/dqV40+ESvsNBZmLK35XmpaWVEIojBRreoJHP/5qk79uIVEiibUmzLrzAzJzLHu4or1 VxR/vrl13DbDWg3iOjlEJwSVlJ1F7rSleYcE2v1dPQFLnCMJEMJ1PlwXOoDfXr6vOgmQ1rv8f Ibus05rdTNlL49fWava5pWPorBApHObu8FaZ7vvQrvvR91LSqknD5n7Bg+I+LJT4swaSeXp4O GXppzP9LfVLM3oFA4G1/nKrSc78F3oSQV1cvf/bKBv+jtDdXIAViEHr7+eH/Xoo5RJKsbjJ4e eyuu8EowKokQeNlPhUzVfToe4SqOrKnf4KjKux9jnaqJOB7Y3eolfqP+jEgjxY6JojOOBi/1o YA21u/PmfkkB5rL3SDupElpVZSKWEO5siDuwN/rqosiXmG9UkgvyNv5yWVZChR5DiBytUSX7N BAvhf27xtQWRCle3G/WZtY/JN7coXhqpuK0cyo729tfg1mnSwoTUfMbuyK4cMNzpMRrhJQzim 01M/1o+ZETx4nezPpdAlRy8crOeGiKMwcu6dI/XjCRmaRADf1hDpiac3JxcGoB1+cUl6iB4aK 3oOR+QoyOllDA8r0NgJDcau+ycOWhe6Wzya/v52XMmk6UoxEeCR5BXUoQbv5PP5CTbKmH+acV 6t9EwQ3hOA7WWNEEInIiadYb7DetzuqBYXWwuWChp37Tvl3zszs8/9fj5MopI5P3kjblteA4p e6NKP2dvTK4DAlGg0p+dJ/dl5weJp6hKMKSU5ICyuzYJZTdivBbdXMlW/VdWTKwbDlLkLuwQz lGdSRCBQiZg55ZZ+AQMNUamkR62ekcXDUpiFt+F6XNeT7w9rBPg41fCRev9oxqtgYahQ1ZG9H aqCugMALW+xu6M= Subject: Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values? 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: Sun, 09 Jan 2022 22:51:30 -0000 Hi Bob, thank you very much for the needed reality check! > On Jan 5, 2022, at 21:42, Bob McMahon = wrote: >=20 > Don't forget about TCP_NOTSENT_LOWAT and things like AIFS. If one = really wants to starve a guest network, set AIFS for that AC to always = lose regardless of CWMIN and CWMAX (traditional EDCAs.) (This is a mean = shift to the arbitration distribution, where one can remove the = distributions' overlaps between the ACs) Then the guest queueing should = back up somewhere else (hopefully at the source.) If it does back up on = the send side host, one can use TCP_NOTSENT_LOWAT to limit that and = effectively only send "relevant" interactive message so-to-speak. Yes do to an unfortunate discussion thread at another place = (where I partly made a fool out of myself) I did some reading on early = EDCA/WMM fairness papers to understand the effect of the different = parameters on cross-AC-"sharing" behavior. But I had not considered = simply playing with AIFS to counter too aggressive airtime regime by my = neighbours (ATM I have no evidence that something untowardly is = happening there so my tit-for-tat approach would still be in the leave = everything at default anyway). > Also, the latency gained and lost is not necessarily zero sum when = considering WiFi MU technologies. I was considering this in the context of a single AP completely = ignoring that wifi development did not stop just because I did not = update my APs ;) > A little delay can allow for an MU vs SU transmission. The MU groups = are basically analogous to IP Multicast where only one RF transmission = is required for many receivers. The primary difference is that IP = multicast has a single source (one to many) while MU is multi-sourced = (many to one.) The point is WiFi MU technologies change things when it = comes to queueing latencies and the engineers writing these algorithms = have to think about this as latency now is driving user experience. Okay, is it completely wrong to assume that leaving everything = in one AC. like AC_BE would give the AP the most leeway to move packets = around slightly to optimize overall throughput (assuming the per packet = delay change is not too large)? Best Regards Sebastian >=20 > Bob >=20 >=20 >=20 > On Wed, Jan 5, 2022 at 10:33 AM Sebastian Moeller = wrote: > Hi Aaron, >=20 >=20 > > On Jan 5, 2022, at 18:11, Aaron Wood wrote: > >=20 > > I'm guessing that schemes like this are mostly aimed-at, or = developed-by, at the enterprise wifi market, where you have mixed uses = being run on the same AP (much like running separate vlans on the same = wired network), to mix both "infrastructure" uses which have priority, = and "guests" networks which have less priority. When I was in that part = of the industry, I was seeing this a lot, the general attempt to move = the QoS and vlans from wired networks into WLAN and WAN links. >=20 > Interesting, thanks! I guess as long as those configuring keep = in mind that prioritization is a zero sum game (at least under load were = it really counts) where the latency gained by one packet is mostly payed = by another packet(s) being delayed. In an uncontrolled environment this = is tricky to get right. I keep fantasizing about a tit-for-tat wifi AP = policy were the AP monitors airtime usage by different ACs and adjusts = its own/its clients AC usage such that it will not be crowded out. >=20 > Regards > Sebastian >=20 >=20 > >=20 > > On Wed, Jan 5, 2022 at 4:28 AM Sebastian Moeller = wrote: > > Hi Toke, hi Jon, > >=20 > > here is a corrected version of what I sent to another list (I = accidentally converted the VA bit-pattern with my calculator set to = base8 so decimal 54 and Range7 instead of the correct decimal 44 and = Range6, which does not change much for the AC mapping as both range6 and = 7 map to AC_VO): > >=20 > > >> hostapd: add wmm qos map set by default > > >> author Felix Fietkau =20 > > >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100) > > >> committer Felix Fietkau =20 > > >> Wed, 3 Nov 2021 22:47:55 +0100 (22:47 +0100) > > >> commit a5e3def1822431ef6436cb493df77006dbacafd6 > > >> tree f4494efd6e08a872524eedb5081564a6f5ece20c tree | = snapshot > > >> parent b14f0628499142a718a68be7d1a7243f7f51ef0a = commit | diff > > >> hostapd: add wmm qos map set by default > > >>=20 > > >> This implements the mapping recommendations from RFC8325, with an > > >> update from RFC8622. This ensures that DSCP marked packets are = properly > > >> sorted into WMM classes. > > >> The map can be disabled by setting iw_qos_map_set to something = invalid > > >> like 'none' > > >>=20 > > >> Signed-off-by: Felix Fietkau > > >=20 > > > Which introduces the following new RFC8325 inspired DSCP to AC = mappings: > > > + set_default iw_qos_map_set = 0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56 > > >=20 > > > Which translates into the following mappings (according to the = hostapd rules below*): > > >=20 > > > unraveling this gets us to (0 is coded as DSCP Exception, the rest = as DSCP ranges): > > >=20 > > > UP DSCP AC PHBs(decDSCP) > > > Ex0 BE BE(0) BE/CS0(0) > > > Range0 2-16 BE CS1(8)**, AF11(10), AF12(12), = AF13(14), CS2(16) > > > Range1 1-1 BK LE(1) > > > Range2 - =20 > > > Range3 18-22 BE AF21(18), AF22(20), AF23(22) > > > Range4 24-38 VI CS3(24), AF31(26), AF32(28), = AF33(30), CS4(32), AF41(34), AF42(36), AF43(38) > > > Range5 40-40 VI CS5(40) > > > Range6 44-46 VO VA(44), EF(46) > > > Range7 48-56 VO CS6(48), CS7(56) > >=20 > > The kernel's default mappings, as far as = https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/queu= es states, seem driven by the top 3 bits of the DSCP field: > > RFC8325 also has a section about the default mappings > >=20 > > UP DSCP AC PHBs(decDSCP) > > Range0 0-7 BE CS0(0) > > Range1 8-15 BK CS1(8), AF11(10), AF12(12), AF13(14) > > Range2 16-23 BK CS2(16), AF21(18), AF22(20), AF23(22) > > Range3 24-31 BE CS3(24), AF31(26), AF32(28), AF33(30) > > Range4 32-39 VI CS4(32), AF41(34), AF42(36), AF43(38) > > Range5 40-47 VI CS5(40), VA(44), EF(46) > > Range6 48-55 VO CS6(48) > > Range7 56-63 VO CS7(56) > >=20 > >=20 > > IMHO RFC8325 and the whole WMM scheme clearly lacks data showing = that is actually delivers on its promises. RFC8325 specifically seems = obsessed in changing mappings such that PHBs align with the 4 WMM = queues, instead of interpreting the fact that the apparent mismatch = between what the IETF thinks about specific PHBs/DSCPs and how they are = treated for most users, as clear sign, that reality does not care... = (probably mostly driven by the elephant in the room, of DSCPs not being = end-to-end). > >=20 > > I agree with Toke that allowing APs to steer specific DSCP use by = applications seems taking an proven non-working idea to the extreme... = (APs can already instruct stations on which DSCPs to map to which AC = (see Felix's patch), which is not used that much, no idea why anybody = thinks that allowing APs even more disruptive changes to end-point = behavior is going to work any better). > >=20 > > Regards > > Sebastian > >=20 > > P.S.: IMHO the biggest change might be the up-prioritisation of EF = from AC_VI to AC_VO, and I am not sure that is a good idea. > >=20 > >=20 > >=20 > > > On Jan 5, 2022, at 13:02, Toke H=C3=B8iland-J=C3=B8rgensen via = Make-wifi-fast wrote: > > >=20 > > > Jon Pike writes: > > >=20 > > >> Heh... So each and everyone in the stadium can have ALL their = data > > >> prioritized above everybody else's! For a more Egalitarian = world! > > >>=20 > > >> Sigh... Meanwhile, back in reality... > > >>=20 > > >> An aside, is that commit in git a significant improvement on the = mappings, > > >> or just some minor tweaks? > > >=20 > > > I *think* they are just minor tweaks, but I don't actually recall = the > > > exact mapping that's the kernel default... > > >=20 > > > -Toke > > > _______________________________________________ > > > Make-wifi-fast mailing list > > > Make-wifi-fast@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/make-wifi-fast > >=20 > > _______________________________________________ > > Make-wifi-fast mailing list > > Make-wifi-fast@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/make-wifi-fast >=20 > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast >=20 > This electronic communication and the information and any files = transmitted with it, or attached to it, are confidential and are = intended solely for the use of the individual or entity to whom it is = addressed and may contain information that is confidential, legally = privileged, protected by privacy laws, or otherwise restricted from = disclosure to anyone else. If you are not the intended recipient or the = person responsible for delivering the e-mail to the intended recipient, = you are hereby notified that any use, copying, distributing, = dissemination, forwarding, printing, or copying of this e-mail is = strictly prohibited. If you received this e-mail in error, please return = the e-mail to the sender, delete it from your computer, and destroy any = printed copy of it.