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 2437E3B29D for ; Wed, 5 Jan 2022 13:33:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1641407604; bh=bYvmZNqv0UyJuu4ABOioj5YqvL28tTHtScFD4RUjSmY=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=NX0D72mlxiiSoXVmvKqyA+P2Wtvme0yMSfgCGhArEV5TrVGE3sGQsOQOLwcR40KWD CaMQlwRQf5wYXT5l01l0TxZ1hBURQazLt3xUpvfKImguDsBScRJAn0r28zyB6G1HG3 5fssznTrAK8N1f8PMTf4hM3gmZ67DPW/3gWfb6tE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([95.116.153.203]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MkHQh-1mgXiX0Y0X-00kheT; Wed, 05 Jan 2022 19:33: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: Wed, 5 Jan 2022 19:33:21 +0100 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Make-Wifi-fast , Jon Pike Content-Transfer-Encoding: quoted-printable Message-Id: <6F6FB992-807F-4F3A-9E46-D6C1B9CBE33D@gmx.de> References: <87r19nb27v.fsf@toke.dk> <87k0febdaq.fsf@toke.dk> To: Aaron Wood X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Provags-ID: V03:K1:YqPXZU4iBKzdNOvaakOq+x7BHoqWSNWRuNMX9A8HwGTphFSUJ2i SZ28zU+FVlQI0I6i3si8ZLXjyYT8sKr/H5YfDfJkI+Z1qExyrzrEAwaZ3Ly92EmtsKQHCKU WgAJ2hX0Q5vLmavcIGmU1Fep7vA++SDV2dY3oR5lqv3qywC5QOaAcbAhAQLFf8cx0J324k5 uGGQlITjuK/G5rRBDS6Xg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:C0StnF3lGmU=:9mmJdrGxPZiIaxWwsYDeWW POb4iocPkjF6a2iB10Blkn4zklJT9HfHjOhxyLKkz4UGgDzh9O8Yrp3goTdgCLl91WPtBSX5P UjTnzKKK+gDFi77Js4rJB4n7I9M7dcGHyYlxAgA22K1LwXNpFkK9d4e6hirm/wF9GGKOFdAWg YUDR0Z7uvCXt8g4B2i9g+on54Qw5pxWCD7JFBXe1h85LLgSH3OVPrK2/NqKLvY4/W31SzOJxJ r/InDNJFXFD+GyllWm273Zj/DiIcT4JK7iPFB4me0WZOdMvZ5Z0ILSbXSwW7rz52ftOS94S5w EuQO+9l2N3RI7z96Q8eBAHVIUT9Y4xRtHDO3iVAZTr8A0f1naSQKRWT38+5DZiv9BC7eqgN2e c9FIotWq1QapQk/3Ydt5JCE0DAUO60q/thcXs+a7m+Kj/+px2GeH14GFEH9xp+7BHtAVOPbN1 hJY6XOPkv4+FJIMEiWK5inzbMrEzI3N4D92WyeNgKu81tOPlf2YkBgpaWuW8q8C1UbQHrIIra oW94D1BKRSH5YRefxttJyi6TrtrIY3D3Z8zza9T5nNWjb/fPpKrn3n6yF+8F/ljIol2UH4acy ZGBy6Iss97FbYjNewWv8oz1jsTgISNqSgg5sFsUTMLp8GmZiVhJi3h5UODvRagwlHr6nji3dg ZFMWC4i4SpnxPqxQXbJQOpAK8U6TdtCO0wu/svvtryfvmLNbBF1O45NUJo8Ahq4MXhbwulkQ1 0ne2ypANnz6tTmYmM7mpwObwOFe4I60LURdQtKlGUHAC0P+drn0zJsn9Ngl6+3hGtSueL4PCm NJPoYwhYCVvpc2xYTaGC0flSjAWJEBEtZ8WdHTt/Fkuvk8NirqTtr0NNZdHLYSZS8eThICKg0 tc4eagK+hfPod5eSw7t8xvlKx1YsbsscZEq5OoiU20heQ7u5FDs5bYs9HK5vcJ371+zyljlHv dD90tkVosIWP7rVVDwRy/PKckp9Wt1p6Uk3Fq/+d9UAr8Zu0YG1yodymCKZMtugU3F1f+7X7+ 58cJlRc8ZiSaIZTU4b/GHH8ecFSkysVE4a3lw+8HUIT6h5gPPfHgAuyMngqNfNmwCt4b93tyd f3ixX9QH5wUOs4= 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: Wed, 05 Jan 2022 18:33:27 -0000 Hi Aaron, > 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. 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. Regards Sebastian >=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