From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 6A2AF3B29E for ; Mon, 10 Jan 2022 11:02:38 -0500 (EST) Received: by mail-ed1-x52d.google.com with SMTP id m4so13957172edb.10 for ; Mon, 10 Jan 2022 08:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6e+QCMyNINCv0DbkNGEx5WzrBlwoNKHQtU5G/pYrhOU=; b=UI6Giz1gP1iUFkzYj+pOz83qvOuQrmw/HHFQtb+cM7E7Ku2juRxqH5Zu8J2clNLuac 5n6TuvXikgpmB7P3NdFXNSUDmrP3iUz/QDRUG1sSdgVTj5dlpkYlmDf5hRCqtnngSZSJ /KMFpAVRb80mwR6HM4B/EcpoRngTWAcKOEja0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6e+QCMyNINCv0DbkNGEx5WzrBlwoNKHQtU5G/pYrhOU=; b=YF/ljx2AkunNAuDkrmmokhLE8T5GS2cIGHReIF2bOhmvxYSvqzn+VgEArnkdFXwoDX LtjcWbRYeqtUEo4WjYKVewzi7R9bshByoVFhIe1wvIi7bEQel55qMCCJsOcwc6AOxz9S pK2H218BwLlJzy8ej9ZcbZVVSjq6zqWJ5Zc+95Xjb2rP5vUNfGrrg7GPvUpH1bEIpvC4 IAhdJ53uXJbz6/4EAxGyziyJm9+hdwSwDV50mRXKgMa05nJNEmea4vEKN68E8Hk4bAXW ectmCAUqbdwhXiU3nGha1bZjs/jNzW3K1NOQgare9JZRjpJKDe3gZ/nsckIGQA9+ni4q RQiw== X-Gm-Message-State: AOAM5313/U069vGDdSCnilImKyupe/cTGHrpyHAMwFgu6VyLManvnZ6X pQIez5E/f/YyOgjcy3ySOoLxzb7xy8p9HU/5sYXtmqPZm87/9JFeolLfOQX6YVvMn53K0OefblG HY2XvNyv8/r5dU1pS9PhJT16Yvn7CJIp0xe7wnF6PJg== X-Google-Smtp-Source: ABdhPJzTWtMMK0iHcQtm4Hrh1Ay613sxZr4VFJcQlWvJ3+8sTqXCh4wBROcpwooDjKC9fgng6K6T/UA2hqLSoCvaPG0= X-Received: by 2002:a05:6402:16c5:: with SMTP id r5mr303505edx.388.1641830557308; Mon, 10 Jan 2022 08:02:37 -0800 (PST) MIME-Version: 1.0 References: <87r19nb27v.fsf@toke.dk> <87k0febdaq.fsf@toke.dk> In-Reply-To: From: Bob McMahon Date: Mon, 10 Jan 2022 11:02:26 -0500 Message-ID: To: Dave Taht Cc: Aaron Wood , Make-Wifi-fast , Jon Pike Content-Type: multipart/alternative; boundary="00000000000026aba805d53c772c" 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: Mon, 10 Jan 2022 16:02:38 -0000 --00000000000026aba805d53c772c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable hmm, curious about the side effects. I perceive the multiple queues with static EDCAs as a poor man's version of adaptive EDCAs where every transmit could have the EDCAs defined via a delayed binding just prior to transmit arbitration. Also, things like push in first out (PIFO) hw queues seem interesting allowing a TCP 3WHS and the first few packets (mouse flow) to jump the line, similar to an express lane at a grocery store. Bob On Sun, Jan 9, 2022 at 6:41 PM Dave Taht wrote: > I've tried to describe the side effects of using all 4 of these queues > in nearly every talk. I'd really like it if the AP drivers just better > multiplexed best effort traffic and modified the values in the beacon. > > I do see more value in pushing out queue selection to the clients, if > used sparingly. > > On Wed, Jan 5, 2022 at 9:12 AM Aaron Wood wrote: > > > > 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, an= d > "guests" networks which have less priority. When I was in that part of t= he > industry, I was seeing this a lot, the general attempt to move the QoS an= d > vlans from wired networks into WLAN and WAN links. > > > > On Wed, Jan 5, 2022 at 4:28 AM Sebastian Moeller > wrote: > >> > >> Hi Toke, hi Jon, > >> > >> 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): > >> > >> >> hostapd: add wmm qos map set by default > >> >> author Felix Fietkau > >> >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100) > >> >> committer Felix Fietkau > >> >> Wed, 3 Nov 2021 22:47:55 +0100 (22:47 +0100) > >> >> commit a5e3def1822431ef6436cb493df77006dbacafd6 > >> >> tree f4494efd6e08a872524eedb5081564a6f5ece20c tree | snapsho= t > >> >> parent b14f0628499142a718a68be7d1a7243f7f51ef0a commit > | diff > >> >> hostapd: add wmm qos map set by default > >> >> > >> >> 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' > >> >> > >> >> Signed-off-by: Felix Fietkau > >> > > >> > 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 > >> > > >> > Which translates into the following mappings (according to the > hostapd rules below*): > >> > > >> > unraveling this gets us to (0 is coded as DSCP Exception, the rest a= s > DSCP ranges): > >> > > >> > 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 - > >> > 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) > >> > >> The kernel's default mappings, as far as > https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/que= ues > states, seem driven by the top 3 bits of the DSCP field: > >> RFC8325 also has a section about the default mappings > >> > >> 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) > >> > >> > >> 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 t= he > elephant in the room, of DSCPs not being end-to-end). > >> > >> I agree with Toke that allowing APs to steer specific DSCP use by > applications seems taking an proven non-working idea to the extreme... (A= Ps > 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). > >> > >> Regards > >> Sebastian > >> > >> P.S.: IMHO the biggest change might be the up-prioritisation of EF fro= m > AC_VI to AC_VO, and I am not sure that is a good idea. > >> > >> > >> > >> > On Jan 5, 2022, at 13:02, Toke H=C3=B8iland-J=C3=B8rgensen via Make-= wifi-fast < > make-wifi-fast@lists.bufferbloat.net> wrote: > >> > > >> > Jon Pike writes: > >> > > >> >> Heh... So each and everyone in the stadium can have ALL their data > >> >> prioritized above everybody else's! For a more Egalitarian world! > >> >> > >> >> Sigh... Meanwhile, back in reality... > >> >> > >> >> An aside, is that commit in git a significant improvement on the > mappings, > >> >> or just some minor tweaks? > >> > > >> > I *think* they are just minor tweaks, but I don't actually recall th= e > >> > exact mapping that's the kernel default... > >> > > >> > -Toke > >> > _______________________________________________ > >> > Make-wifi-fast mailing list > >> > Make-wifi-fast@lists.bufferbloat.net > >> > https://lists.bufferbloat.net/listinfo/make-wifi-fast > >> > >> _______________________________________________ > >> Make-wifi-fast mailing list > >> Make-wifi-fast@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/make-wifi-fast > > > > _______________________________________________ > > Make-wifi-fast mailing list > > Make-wifi-fast@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/make-wifi-fast > > > > -- > I tried to build a better future, a few times: > https://wayforward.archive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org > > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > 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= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --00000000000026aba805d53c772c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hmm, curious about the side effects.

I perceive the= multiple queues with static EDCAs as a poor man's version of adaptive = EDCAs where every transmit could have the EDCAs defined via a delayed bindi= ng just prior to transmit arbitration. Also, things like push in first out (PIFO) hw queues=C2=A0seem interes= ting allowing a TCP 3WHS and the first few packets (mouse flow) to jump the= line, similar=C2=A0to an express lane at a grocery=C2=A0store.=C2=A0
Bob

On Sun, Jan 9, 2022 at 6:41 PM Dave Taht <dave.taht@gmail.com> wrote:
I've tried to describe the side effect= s of using all 4 of these queues
in nearly every talk. I'd really like it if the AP drivers just better<= br> multiplexed best effort traffic and modified the values in the beacon.

I do see more value in pushing out queue selection to the clients, if
used sparingly.

On Wed, Jan 5, 2022 at 9:12 AM Aaron Wood <woody77@gmail.com> wrote:
>
> I'm guessing that schemes like this are mostly aimed-at, or develo= ped-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 &quo= t;guests" networks which have less priority.=C2=A0 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.
>
> On Wed, Jan 5, 2022 at 4:28 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>> Hi Toke, hi Jon,
>>
>> here is a corrected version of what I sent to another list (I acci= dentally converted the VA bit-pattern with my calculator set to base8 so de= cimal 54 and Range7 instead of the correct decimal 44 and Range6, which doe= s not change much for the AC mapping as both range6 and 7 map to AC_VO): >>
>> >> hostapd: add wmm qos map set by default
>> >> author=C2=A0 =C2=A0 =C2=A0 =C2=A0Felix Fietkau <nbd@nbd.name>
>> >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
>> >> committer=C2=A0 =C2=A0 Felix Fietkau <nbd@nbd.name>
>> >> Wed, 3 Nov 2021 22:47:55 +0100 (22:47 +0100)
>> >> commit=C2=A0 =C2=A0 =C2=A0 =C2=A0a5e3def1822431ef6436cb49= 3df77006dbacafd6
>> >> tree f4494efd6e08a872524eedb5081564a6f5ece20c=C2=A0 =C2= =A0 =C2=A0 =C2=A0 tree | snapshot
>> >> parent=C2=A0 =C2=A0 =C2=A0 =C2=A0b14f0628499142a718a68be7= d1a7243f7f51ef0a=C2=A0 =C2=A0 =C2=A0 =C2=A0 commit | diff
>> >> hostapd: add wmm qos map set by default
>> >>
>> >> This implements the mapping recommendations from RFC8325,= with an
>> >> update from RFC8622. This ensures that DSCP marked packet= s are properly
>> >> sorted into WMM classes.
>> >> The map can be disabled by setting iw_qos_map_set to some= thing invalid
>> >> like 'none'
>> >>
>> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>> >
>> > Which introduces the following new RFC8325 inspired DSCP to A= C mappings:
>> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0set_default iw_qos_map_set 0,0,2,= 16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
>> >
>> > Which translates into the following mappings (according to th= e hostapd rules below*):
>> >
>> > unraveling this gets us to (0 is coded as DSCP Exception, the= rest as DSCP ranges):
>> >
>> > UP=C2=A0 =C2=A0 DSCP=C2=A0 =C2=A0 AC=C2=A0 =C2=A0 =C2=A0 PHBs= (decDSCP)
>> > Ex0=C2=A0 =C2=A0BE=C2=A0 =C2=A0 =C2=A0 BE(0)=C2=A0 =C2=A0BE/C= S0(0)
>> > Range0=C2=A0 =C2=A0 =C2=A0 =C2=A0 2-16=C2=A0 =C2=A0 BE=C2=A0 = =C2=A0 =C2=A0 CS1(8)**, AF11(10), AF12(12), AF13(14), CS2(16)
>> > Range1=C2=A0 =C2=A0 =C2=A0 =C2=A0 1-1=C2=A0 =C2=A0 =C2=A0BK= =C2=A0 =C2=A0 =C2=A0 LE(1)
>> > Range2=C2=A0 =C2=A0 =C2=A0 =C2=A0 -
>> > Range3=C2=A0 =C2=A0 =C2=A0 =C2=A0 18-22=C2=A0 =C2=A0BE=C2=A0 = =C2=A0 =C2=A0 AF21(18), AF22(20), AF23(22)
>> > Range4=C2=A0 =C2=A0 =C2=A0 =C2=A0 24-38=C2=A0 =C2=A0VI=C2=A0 = =C2=A0 =C2=A0 CS3(24), AF31(26), AF32(28), AF33(30), CS4(32), AF41(34), AF4= 2(36), AF43(38)
>> > Range5=C2=A0 =C2=A0 =C2=A0 =C2=A0 40-40=C2=A0 =C2=A0VI=C2=A0 = =C2=A0 =C2=A0 CS5(40)
>> > Range6=C2=A0 =C2=A0 =C2=A0 =C2=A0 44-46=C2=A0 =C2=A0VO=C2=A0 = =C2=A0 =C2=A0 VA(44), EF(46)
>> > Range7=C2=A0 =C2=A0 =C2=A0 =C2=A0 48-56=C2=A0 =C2=A0VO=C2=A0 = =C2=A0 =C2=A0 CS6(48), CS7(56)
>>
>> The kernel's default mappings, as far as https://wireless.wiki.kernel.org/en/developer= s/documentation/mac80211/queues states, seem driven by the top 3 bits o= f the DSCP field:
>> RFC8325 also has a section about the default mappings
>>
>> UP=C2=A0 =C2=A0 =C2=A0 DSCP=C2=A0 =C2=A0 AC=C2=A0 =C2=A0 =C2=A0 PH= Bs(decDSCP)
>> Range0=C2=A0 0-7=C2=A0 =C2=A0 =C2=A0BE=C2=A0 =C2=A0 =C2=A0 CS0(0)<= br> >> Range1=C2=A0 8-15=C2=A0 =C2=A0 BK=C2=A0 =C2=A0 =C2=A0 CS1(8), AF11= (10), AF12(12), AF13(14)
>> Range2=C2=A0 16-23=C2=A0 =C2=A0BK=C2=A0 =C2=A0 =C2=A0 CS2(16), AF2= 1(18), AF22(20), AF23(22)
>> Range3=C2=A0 24-31=C2=A0 =C2=A0BE=C2=A0 =C2=A0 =C2=A0 CS3(24), AF3= 1(26), AF32(28), AF33(30)
>> Range4=C2=A0 32-39=C2=A0 =C2=A0VI=C2=A0 =C2=A0 =C2=A0 CS4(32), AF4= 1(34), AF42(36), AF43(38)
>> Range5=C2=A0 40-47=C2=A0 =C2=A0VI=C2=A0 =C2=A0 =C2=A0 CS5(40), VA(= 44), EF(46)
>> Range6=C2=A0 48-55=C2=A0 =C2=A0VO=C2=A0 =C2=A0 =C2=A0 CS6(48)
>> Range7=C2=A0 56-63=C2=A0 =C2=A0VO=C2=A0 =C2=A0 =C2=A0 CS7(56)
>>
>>
>> IMHO RFC8325 and the whole WMM scheme clearly lacks data showing t= hat is actually delivers on its promises. RFC8325 specifically seems obsess= ed 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, a= s clear sign, that reality does not care... (probably mostly driven by the = elephant in the room, of DSCPs not being end-to-end).
>>
>> 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 t= o work any better).
>>
>> Regards
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sebastian
>>
>> 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.
>>
>>
>>
>> > On Jan 5, 2022, at 13:02, Toke H=C3=B8iland-J=C3=B8rgensen vi= a Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net> wrote:
>> >
>> > Jon Pike <jonpike54@gmail.com> writes:
>> >
>> >> Heh...=C2=A0 So each and everyone in the stadium can have= ALL their data
>> >> prioritized above everybody else's!=C2=A0 For a more = Egalitarian world!
>> >>
>> >> Sigh...=C2=A0 =C2=A0Meanwhile, back in reality...
>> >>
>> >> An aside, is that commit in git a significant improvement= on the mappings,
>> >> or just some minor tweaks?
>> >
>> > I *think* they are just minor tweaks, but I don't actuall= y recall the
>> > exact mapping that's the kernel default...
>> >
>> > -Toke
>> > _______________________________________________
>> > Make-wifi-fast mailing list
>> > Make-wifi-fast@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/lis= tinfo/make-wifi-fast
>>
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo= /make-wifi-fast
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ma= ke-wifi-fast



--
I tried to build a better future, a few times:
https://wayforward.archive.org/?sit= e=3Dhttps%3A%2F%2Fwww.icei.org

Dave T=C3=A4ht CEO, TekLibre, LLC
_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast

This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly 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. --00000000000026aba805d53c772c--