Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Jon Pike]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

Might it have to do with these RFC's?

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a5e3def1822431ef6436cb493df77006dbacafd6


>
> ---------- Forwarded message ----------
> From: "Toke Høiland-Jørgensen" <toke@toke.dk>
> To: make-wifi-fast@lists.bufferbloat.net
> Cc:
> Bcc:
> Date: Mon, 03 Jan 2022 22:06:06 +0100
> Subject: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP
> values?
> During a discussion on netdev[0], an upcoming WiFi standard that will
> allow the AP to inform the clients about which DSCP values to set for
> particular flows was mentioned as a use case. Anyone knows anything more
> about this?
>
> -Toke
>
> [0]
> https://lore.kernel.org/all/CANP3RGeNVSwSfb9T_6Xp8GyggbwnY7YQjv1Fw5L2wTtqiFJbpw@mail.gmail.com/
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1506 bytes --]

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Toke Høiland-Jørgensen]

Jon Pike <jonpike54@gmail.com> writes:

> Might it have to do with these RFC's?
>
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a5e3def1822431ef6436cb493df77006dbacafd6

Don't think so; that's just the standard static mapping. Bob pointed me
to this:
https://www.wi-fi.org/downloads-registered-guest/Wi-Fi_CERTIFIED_QoS_Management_Technology_Overview_202110.pdf/37425

which seems to be the right thing (you can just input garbage into the
form to download the PDF). It is a mechanism where the AP and client can
request of each other to apply certain DSCP markings (and thus WiFi WMM
classes) to certain flows. The document has gems like:


> To deliver good quality of experience in these applications it is
> essential that Wi-Fi networks support a range of service categories
> that differentiate and prioritize data flows for such applications.
> Wi-Fi networks that give equal priority access to all connected
> devices and data flows cannot provide the throughput and stability
> required when traffic demands exceed the available bandwidth. This
> negatively impacts the user experience.

and:

> The efficient use of unlicensed spectrum used by Wi-Fi requires good
> faith use of mechanisms that enable prioritized access to that
> spectrum. Therefore, it is important that all entities that leverage
> Wi-Fi QoS Management features do so in a reasonable and responsible
> manner.

So yeah, that'll all end well...

Also, what is it with people wanting to provide AR in sports stadiums?
Crops up in all these "future of wireless" type marketing presos...

-Toke

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Jon Pike]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

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?

Jon

On Tue, Jan 4, 2022, 1:49 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Jon Pike <jonpike54@gmail.com> writes:
>
> > Might it have to do with these RFC's?
> >
> >
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a5e3def1822431ef6436cb493df77006dbacafd6
>
> Don't think so; that's just the standard static mapping. Bob pointed me
> to this:
>
>

[-- Attachment #2: Type: text/html, Size: 1332 bytes --]

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Toke Høiland-Jørgensen]

Jon Pike <jonpike54@gmail.com> 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

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Sebastian Moeller]

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 <nbd@nbd.name>	
>> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
>> committer	Felix Fietkau <nbd@nbd.name>	
>> 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 invalid
>> like 'none'
>> 
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> 
> 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 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/queues 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 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 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øiland-Jørgensen via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net> wrote:
> 
> Jon Pike <jonpike54@gmail.com> 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

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 5488 bytes --]

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.

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 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 <nbd@nbd.name>
> >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
> >> committer    Felix Fietkau <nbd@nbd.name>
> >> 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 invalid
> >> like 'none'
> >>
> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> >
> > 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 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/queues
> 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 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 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øiland-Jørgensen via Make-wifi-fast <
> make-wifi-fast@lists.bufferbloat.net> wrote:
> >
> > Jon Pike <jonpike54@gmail.com> 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

[-- Attachment #2: Type: text/html, Size: 7189 bytes --]

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Sebastian Moeller]

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 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


> 
> 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 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 <nbd@nbd.name>    
> >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
> >> committer    Felix Fietkau <nbd@nbd.name>    
> >> 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 invalid
> >> like 'none'
> >> 
> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> > 
> > 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 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/queues 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 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 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øiland-Jørgensen via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net> wrote:
> > 
> > Jon Pike <jonpike54@gmail.com> 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

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 8587 bytes --]

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 <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
> 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
>
>
> >
> > 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
> 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 <nbd@nbd.name>
> > >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
> > >> committer    Felix Fietkau <nbd@nbd.name>
> > >> 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 invalid
> > >> like 'none'
> > >>
> > >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> > >
> > > 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 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/queues
> 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 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 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øiland-Jørgensen via Make-wifi-fast <
> make-wifi-fast@lists.bufferbloat.net> wrote:
> > >
> > > Jon Pike <jonpike54@gmail.com> 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

-- 
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.

[-- Attachment #2: Type: text/html, Size: 10925 bytes --]

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Sebastian Moeller]

Hi Bob,

thank you very much for the needed reality check!


> On Jan 5, 2022, at 21:42, Bob McMahon <bob.mcmahon@broadcom.com> wrote:
> 
> 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


> 
> 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 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
> 
> 
> > 
> > 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 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 <nbd@nbd.name>    
> > >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
> > >> committer    Felix Fietkau <nbd@nbd.name>    
> > >> 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 invalid
> > >> like 'none'
> > >> 
> > >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> > > 
> > > 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 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/queues 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 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 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øiland-Jørgensen via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net> wrote:
> > > 
> > > Jon Pike <jonpike54@gmail.com> 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
> 
> 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.

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Dave Taht]

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 <woody77@gmail.com> 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, 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.
>
> 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 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 <nbd@nbd.name>
>> >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
>> >> committer    Felix Fietkau <nbd@nbd.name>
>> >> 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 invalid
>> >> like 'none'
>> >>
>> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>> >
>> > 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 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/queues 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 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 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øiland-Jørgensen via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net> wrote:
>> >
>> > Jon Pike <jonpike54@gmail.com> 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



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

Dave Täht CEO, TekLibre, LLC

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 8083 bytes --]

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 <http://web.mit.edu/pifo/> 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 <dave.taht@gmail.com> 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 <woody77@gmail.com> 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, 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.
> >
> > 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
> 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 <nbd@nbd.name>
> >> >> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
> >> >> committer    Felix Fietkau <nbd@nbd.name>
> >> >> 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
> invalid
> >> >> like 'none'
> >> >>
> >> >> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> >> >
> >> > 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 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/queues
> 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 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 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øiland-Jørgensen via Make-wifi-fast <
> make-wifi-fast@lists.bufferbloat.net> wrote:
> >> >
> >> > Jon Pike <jonpike54@gmail.com> 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
>
>
>
> --
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

-- 
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.

[-- Attachment #2: Type: text/html, Size: 10980 bytes --]

Re: [Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Jon Pike]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

And there I was, thinking it was some kind of improvement on things...

Sounds like I should go from insuring I have it,  to figuring out how to
disable it altogether?  An "Unmark them all and let Airtime Fairness sort
them out" situation would be better?  Or is there something sensible
inbetween?


> On Wed, Jan 5, 2022 at 4:28 AM Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> Hi Toke, hi Jon,
>>
>> 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).
>>
>> 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).
>>
>> 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.
>>
>>
>> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast


>
>

[-- Attachment #2: Type: text/html, Size: 2752 bytes --]

[Make-wifi-fast] Upcoming WiFi standard to set per-flow DSCP values?

[Toke Høiland-Jørgensen]

During a discussion on netdev[0], an upcoming WiFi standard that will
allow the AP to inform the clients about which DSCP values to set for
particular flows was mentioned as a use case. Anyone knows anything more
about this?

-Toke

[0] https://lore.kernel.org/all/CANP3RGeNVSwSfb9T_6Xp8GyggbwnY7YQjv1Fw5L2wTtqiFJbpw@mail.gmail.com/