Question regarding default qos_map_set (a5e3def1822431ef6436cb493df77006dbacafd6)

Sebastian Moeller moeller0 at gmx.de
Tue Dec 14 14:26:58 PST 2021


Dear Felix,

with great joy did I notice that you enabled the qos_map_set feature of hostapd and supply a new default map that aligns OpenWrt's DSCP-2-AC mapping with RFC8325

Cimmit: a5e3def1822431ef6436cb493df77006dbacafd6

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 sets:
set_default iw_qos_map_set 0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56

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)

**) This used to be in AC_BK but LE is the new CS1 ;) (I think this changes is justified, as in the past Comcast was reported to inject lots of CS1 marked packets into leaf networks without CS1 actually denoting background/lower effort).


My questions for this map now are:
a) why the incomplete coverage of the 6bit DSCP value range?
This mapping leaves out DSCPs 17, 23, 39, 41-43, 47, 57-63 completely, which is odd (I assume these will map to UP_0 but am not sure). RFC8325 recommends to map all not explicitly mentioned DSCPs to UP0, which might allow a conceptually simpler qos_map_set setting all DSCPs to UP_0 and leveraging the up to 21 exceptions (see * below) for the relevant mappings of the named PHBs:

1,1,18,3,20,3,22,3,24,4,26,4,28,4,30,4,32,4,34,4,36,4,38,4,40,5,46,6,48,7,54,7,56,7,0,63,255,255,255,255,255,255,255,255,255,255,255,255,255,255

Which has 3 potentially desirable properties:
1) it makes the mappings of anything not AC_BE explicit
2)has no unexplained gaps and 
3) follows RFC8325 recommendation to only map the enumerated PHBs.

On the other hand it clearly is longer and untested (my router is still on too old an OpenWrt version for qos_map_set to be supported I think) and it assumes that exceptions will get evaluated and honored even if the UP range is set to 255/255.

What do you think?


Best Regards
	Sebastian

P.S.: I am 100% certain that RFC8325's recommendations were actually tested under mildly adverse real life conditions (I would guess that was tested in clean enterprise WiFi environments with appropriate admission control), EF markings are not super rare and putting these in AC_VO can pummel throughput in lower ACs to some degree (if there is more than the occasional EF packet).







*) ### 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.









More information about the openwrt-devel mailing list