[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 at nbd.name>	
>> Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
>> committer	Felix Fietkau <nbd at 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 at 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 at lists.bufferbloat.net> wrote:
> 
> Jon Pike <jonpike54 at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast