From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 ED8863B29D for ; Wed, 5 Jan 2022 15:42:56 -0500 (EST) Received: by mail-ed1-x536.google.com with SMTP id w16so1175622edc.11 for ; Wed, 05 Jan 2022 12:42:56 -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=/iOygv0+6bNt58lr4tf0cunDdZR040WNFdigL96nhME=; b=CY+gqbp/Rg1r65CSJe57LGlVyZ3qU0SyeOfQm2VNwm9043/AJGLurhCNnboXGc3eb7 BLJFtiLZDUCM2t8j4xAWkfsSEP9QQ5yh+/IbctAg42Nbvbqm0GJrauI7K0IdQfk8n2GT JhQZN+/FuJWEdNcz+Uc9lkPdqRJTszflSpso4= 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=/iOygv0+6bNt58lr4tf0cunDdZR040WNFdigL96nhME=; b=pCF7+ruDQuMUn2ReMC0+Xy43jbLaIwRxfBpIB5mDhjePTJ+1jXdogIXUS22TbI/Gpo xcDqrsubQXixDjNLMoDfYF7Xa9eARZ8Sk7BA0kyyfFcaQ9uea81lCh9ooWYrXnMjh3/J qX0l2W0IIw38gbiGFIeOvEs5Bqcf6TQnVqAxnMGPMIHLiEoloIbiIdpXKY+JgUgrvd/A vmmicWMjxU2sGqq1D9XMMk559XHr4bSR9jEH8qenZTxj4uK1qCa6hF+rod69NAe9Lzqd gcNoIgg7iAI2oB5J5zU4BVlc2fqYEBA/dddrX6bF4+YJ/WbjqPLTkVx0r4arqB24Geu5 b7MQ== X-Gm-Message-State: AOAM533rXIHSK7jcbRnpNsMYegANQZXdNnuyHBsTJYWIhRbdZCzGu1Bo 2lBbH6z82UfhT0wTAS+swYiqxqlDPNZR/Ezs9jPWyWkQ5qC6ayT7WD9GrscKDMcbZEOKw8lwHa6 6hWGWjQyGN8XruaT6sQRlDeFjwq448f/P2C7nIR9VhA== X-Google-Smtp-Source: ABdhPJwVZ5rc/cymF+Vj6c2Ck6AQroY9IGTgG1XtRAr0+lDZHzf7cL+poEJIyAcuSH7V2xdpUGR+Rx1umeqXHe2d3pQ= X-Received: by 2002:a05:6402:12c4:: with SMTP id k4mr53344887edx.218.1641415375721; Wed, 05 Jan 2022 12:42:55 -0800 (PST) MIME-Version: 1.0 References: <87r19nb27v.fsf@toke.dk> <87k0febdaq.fsf@toke.dk> <6F6FB992-807F-4F3A-9E46-D6C1B9CBE33D@gmx.de> In-Reply-To: <6F6FB992-807F-4F3A-9E46-D6C1B9CBE33D@gmx.de> From: Bob McMahon Date: Wed, 5 Jan 2022 12:42:44 -0800 Message-ID: To: Sebastian Moeller Cc: Aaron Wood , Make-Wifi-fast , Jon Pike Content-Type: multipart/alternative; boundary="00000000000066845605d4dbcc6f" 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 20:42:57 -0000 --00000000000066845605d4dbcc6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. Also, the latency gained and lost is not necessarily zero sum when considering WiFi MU technologies. 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. Bob On Wed, Jan 5, 2022 at 10:33 AM Sebastian Moeller wrote: > Hi Aaron, > > > > On Jan 5, 2022, at 18:11, 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. > > 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 polic= y > were the AP monitors airtime usage by different ACs and adjusts its own/i= ts > clients AC usage such that it will not be crowded out. > > Regards > Sebastian > > > > > > 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 | snapshot > > >> 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 inval= id > > >> 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 hostap= d > rules below*): > > > > > > unraveling this gets us to (0 is coded as DSCP Exception, the rest as > 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 i= s > 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 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 via Make-w= ifi-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 the > > > 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 --=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. --00000000000066845605d4dbcc6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Don't forget about TCP_NOTSENT_LOWAT and things like A= IFS. If one really wants=C2=A0to starve a guest network, set AIFS for that = AC to always lose regardless of CWMIN and CWMAX (traditional EDCAs.)=C2=A0 = (This is a mean=C2=A0shift to the arbitration distribution, where one can r= emove the distributions' overlaps between the ACs) Then the guest queue= ing should back up somewhere else (hopefully at the source.) If it does bac= k up on the send side host, one can use TCP_NOTSENT_LOWAT to limit that and= effectively only send "relevant" interactive=C2=A0message so-to-= speak.

Also, the latency gained and lost is not necessarily zero sum= when considering WiFi MU technologies. A little delay can allow for an MU = vs SU transmission. The MU groups are basically analogous=C2=A0to IP Multic= ast where only one RF transmission=C2=A0is required for many receivers. The= primary difference is that IP multicast has a single=C2=A0source (one to m= any) while MU is multi-sourced (many to one.) The point is WiFi MU technolo= gies change things when it comes to queueing latencies and the engineers wr= iting these algorithms have to think about this=C2=A0as latency now is driv= ing user experience.

Bob



On Wed, Jan 5, 2022 at 10:33 AM = Sebastian Moeller <moeller0@gmx.de> wrote:
Hi = Aaron,


> On Jan 5, 2022, at 18:11, 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.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Interesting, thanks! I guess as long as those c= onfiguring keep in mind that prioritization is a zero sum game (at least un= der load were it really counts) where the latency gained by one packet is m= ostly payed by another packet(s) being delayed. In an uncontrolled environm= ent this is tricky to get right. I keep fantasizing about a tit-for-tat wif= i 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
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian


>
> 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 accident= ally converted the VA bit-pattern with my calculator set to base8 so decima= l 54 and Range7 instead of the correct decimal 44 and Range6, which does no= t 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>=C2=A0 =C2=A0 <= br> > >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
> >> committer=C2=A0 =C2=A0 Felix Fietkau <nbd@nbd.name>=C2=A0 =C2=A0
> >> Wed, 3 Nov 2021 22:47:55 +0100 (22:47 +0100)
> >> commit=C2=A0 =C2=A0 =C2=A0 =C2=A0a5e3def1822431ef6436cb493df7= 7006dbacafd6
> >> tree f4494efd6e08a872524eedb5081564a6f5ece20c=C2=A0 =C2=A0 = =C2=A0 =C2=A0 tree | snapshot
> >> parent=C2=A0 =C2=A0 =C2=A0 =C2=A0b14f0628499142a718a68be7d1a7= 243f7f51ef0a=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, wit= h an
> >> update from RFC8622. This ensures that DSCP marked packets ar= e properly
> >> sorted into WMM classes.
> >> The map can be disabled by setting iw_qos_map_set to somethin= g invalid
> >> like 'none'
> >>
> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> >
> > Which introduces the following new RFC8325 inspired DSCP to AC ma= ppings:
> > +=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 the ho= stapd rules below*):
> >
> > unraveling this gets us to (0 is coded as DSCP Exception, the res= t as DSCP ranges):
> >
> > UP=C2=A0 =C2=A0 DSCP=C2=A0 =C2=A0 AC=C2=A0 =C2=A0 =C2=A0 PHBs(dec= DSCP)
> > Ex0=C2=A0 =C2=A0BE=C2=A0 =C2=A0 =C2=A0 BE(0)=C2=A0 =C2=A0BE/CS0(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 -=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), AF42(3= 6), 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/developers/do= cumentation/mac80211/queues states, seem driven by the top 3 bits of th= e 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 PHBs(d= ecDSCP)
> Range0=C2=A0 0-7=C2=A0 =C2=A0 =C2=A0BE=C2=A0 =C2=A0 =C2=A0 CS0(0)
> 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), AF21(18= ), AF22(20), AF23(22)
> Range3=C2=A0 24-31=C2=A0 =C2=A0BE=C2=A0 =C2=A0 =C2=A0 CS3(24), AF31(26= ), AF32(28), AF33(30)
> Range4=C2=A0 32-39=C2=A0 =C2=A0VI=C2=A0 =C2=A0 =C2=A0 CS4(32), AF41(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 that = is actually delivers on its promises. RFC8325 specifically seems obsessed i= n changing mappings such that PHBs align with the 4 WMM queues, instead of = interpreting the fact that the apparent mismatch between what the IETF thin= ks about specific PHBs/DSCPs and how they are treated for most users, as cl= ear sign, that reality does not care... (probably mostly driven by the elep= hant in the room, of DSCPs not being end-to-end).
>
> I agree with Toke that allowing APs to steer specific DSCP use by appl= ications 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 all= owing APs even more disruptive changes to end-point behavior is going to wo= rk 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 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 Ma= ke-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 Egal= itarian 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 actually re= call the
> > exact mapping that's the kernel default...
> >
> > -Toke
> > _______________________________________________
> > Make-wifi-fast mailing list
> > Make-wifi-fast@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinf= o/make-wifi-fast
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ma= ke-wifi-fast

_______________________________________________
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. --00000000000066845605d4dbcc6f--