Subject: [tsvwg] NQB 45 AC mapping issue in OpenWrt snapshots

From: Sebastian Moeller <[email-masked]>
Date: Wed, 15 Dec 2021 14:09:01 +0100

Dear Greg, dear list

I just noticed a relevant change to OpenWrt default WiFi settings:

hostapd: add wmm qos map set by default
author	Felix Fietkau <[email-masked]>	
Wed, 3 Nov 2021 22:40:53 +0100 (22:40 +0100)
committer	Felix Fietkau <[email-masked]>	
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 <[email-masked]>

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	EF(46)
Range7	48-56	VO	CS6(48), VA(54), CS7(56)

Notice how your proposed decDSCP 45 maps into Range6 and hence AC_VO here?

I already wrote an email to the OpenWrt list proposing to honor RFC8325 request to map all not explicitly listed PHBs/DSCPs to AC_BE, but the fate of my proposal in OpenWrt  is doubtful, and even if applied will need to be changed once NQB is RFCd. But in all honesty this highlights a problem between your expectations how devices in the wild will behave when confronted with decDSCP 45 and how they will behave.

Your draft says:
"Similarly, systems that utilize [RFC8325] but that are unable to
   fully support the PHB requirements, SHOULD map the recommended NQB
   code point 45 (or the locally determined alternative) to UP_5 in the
   "Video" Access Category."

But RFC8325 states explicitly:
"All unused codepoints are RECOMMENDED to be mapped to UP 0
  (See Security Considerations below)"

So without administrative intervention NQB in an RFC8325 WiFI deployment will probably map to UP 0 / AC_BE, while in bog standard default WiFi WMM it will map to AC_VI. 

This also highlights the IMHO safest path forward, converging on using decDSCP 5 for NQB and recommending NQB aware APs to use an equivalent to hostapd's qos_map_set to configure special treatment for "5", an approach which inherently is safe by design. Yes, other DSCP value proposals in the past have not considered the unfortunate intricacies of WiFI WMM mappings, and we can hardly retroactively fix these, but we can make sure that we are not adding to the problem going forward.

Regards
	Sebastian

*) 
### hostapd/wpad qos_map
# QoS Map Set configuration
#
# Comma delimited QoS Map Set in decimal values
# (see IEEE Std 802.11-2012, 8.4.2.97)
#
# format:
# [<DSCP Exceptions[DSCP,UP]>,]<UP 0 range[low,high]>,...<UP 7 range[low,high]>
#
# There can be up to 21 optional DSCP Exceptions which are pairs of DSCP Value
# (0..63 or 255) and User Priority (0..7). This is followed by eight DSCP Range
# descriptions with DSCP Low Value and DSCP High Value pairs (0..63 or 255) for
# each UP starting from 0. If both low and high value are set to 255, the
# corresponding UP is not used.