Ah I noticed the part of the discussion that said the hostapd modification is a challenge in OpenWrt. Alright, will try to see if I can figure it out, running grep -r qos_map /; to see if I find where it is defined and/or from what script it is generated.
I believe this is the standard IEEE mapping, nothing Linux specific here... Also @ArnoLP if you use AC_VO on wifi make sure that you understand the tradeoff, AC_VO does only allows less aggregation that e.g. AC_VI and hence, since the per TX-OP overhead stays pretty much the same is less bandwidth efficient than the lower ACs. If the traffic you want to route to AC_VO is sparse, then you are all set, but if you flood AC_VO you will effectively dronw out all other users of the same channel, including traffiv in AC_VI , AC_BE, AC_BK, but also traffic on neighboring APs on the same channel.... So by all means, use AAC_VO, but please consider the side-effects before doing so blindly.
Have a look at the hostapd_cli help output, at least in master you will find among others:
set_qos_map_set <arg,arg,...> = set QoS Map set element
send_qos_map_conf <addr> = send QoS Map Configure frame
These look like methods useful for testing at least.... (Playing with these is on my TODO stack, but time is constantly short and other things interfere).
It's been bog standard since the early days of DSCP for SIP based VOIP phones to use EF=46 for their audio. I can't understand why anyone would think that shouldn't go into the AC_VO queue. It is explicitly for VOICE.
What linux does is essentially pretend that DSCP is IP precedence, which is the same thing as mapping all DSCP to their CS class... it puts:
Whether this is IEEE standard or not, the de facto standard for voice is EF which maps to CS5, but should go in the VOICE queue, because the voice queue behavior was explicitly designed for voice traffic.
As you can see, if you have a packet go WAN -> Cake -> Smart Switch -> AP there is a pretty strong impedance mismatch at every step...
For example, if you leave CS0 on a default packet, it will go into best effort in cake, low priority in the switch, and best effort in the AP.
On the other hand if you put CS1 for bulk, it will go Bulk in cake, best-effort in the switch (ahead of CS0), and Bulk in the AP.
Suppose you change your CS0 default to CS2: it'll go VIDEO in cake, Normal in the switch, and BULK in the AP...
Suppose you change your CS0 default to CS3: It'll go VIDEO in cake, normal in the switch, and Best Effort in the AP...
Rolling my eyes so hard it hurts!
Fortunately the switch is probably less important, unless you have lots of bulk transfers like heavy NFS traffic or a big network of video surveillance cameras, you can probably get away with not worrying about the difference between say bulk and best effort and just being satisfied that things like game and voice packets wind up in high prio in the switch...
The choke points for most people are at the WAN and the AP. But gigabit WAN is becoming a more common thing! At that point choke points are mainly in the AP!
Well, the only indication is in the _VO part of AC_VO, would you still use the same arguments of the name would be AC_NC for network control? ;).
Given that WMM implements a rather strict priority system (AC_VO can shut out AC_BE and AC_BK completely, thereby starving all flows in those ACs) I do believe that we are lucky that EF maps into AC_VI, there is quite a number of applications that use EF without being considerate about bandwidth...
That said the IETF is on your side (see [https://tools.ietf.org/html/rfc8325])(https://tools.ietf.org/html/rfc8325), but again I note that that RFC does not cite actual studies supporting the proposed mappings. Now, I agree that conceptionally these proposed mappings seem sane, but I am always a bit weary about unexpected side-effects especially when the side-effects can be to effectively starve all other lower priority users of the same WiFi channel...
I actually believe this to be sane, the highest priority tier (in a strict priority scheme) should be reserved for carefully selected admission controlled traffic
Honestly, I think that the whole 6 dscp bits should be partitioned into two groups of three, 3 bits for the current networks re-mapped DSCP and 3 bits for the DSCP the sending endpoint requested. That way the intent remains conserved and the intermediate hops have a chance of doing their own thing. But I digress.
IMHO this is rather sane and similar to how the priority levels should have been implemented in the first place. Alas, I also understand why BK was hoisted to CS1 initially, to stay backward compatible and do no harm to innocent bystanders...
I knew you did that and always wondered why exactly, now I know, and as I assumed with a decent rationale.
Well, I try to keep things simple, but I also like to use 3 tiers: BK, BE, and IMPORTANT, but I basically want these as infrastructure which I rarely exercise (I think I elevate ssh into IMPORTANT). But again I run a fairly small, well-behaved network wich avoids all the tricky infrastructure pieces that require special care (opting for a ip-phone base connected via ethernet to my router and use DECT for allowing to use the handset in the whole apartment avoids a lot of complications).
Yes, that is an unfortunate default in the switch (understandable and clean, but unfortunate), I do have no issues with cake putting EF, VA in the highest tier as cake will take care not to starve the lower tiers (unlike WMM).
I feel your pain.
Yes we are getting there! I believe that at least for Wifi <6 the airtime fairness approach pioneered by @tohojo and others in ath9k and ath10k goes a long way in making wifi have acceptable latency under load.
I tried the suggestion of @moeller0 and checked out hostapd_cli, I figured out it's a package you have to install, that took me a while to understand. Ran it and attempted hostapd_cli set_qos_map_set 46,6 and got an error UNKNOWN COMMAND. I typed in hostapd_cli wlfjhfljhlfwgerh to see what kind of error I get and it was Unknown command : 'wlfjhfljhlfwgerh', so I'm guessing UNKNOWN COMMAND in all capital letters must come from some underlying utility (I am told hostapd itself which hostapd_cli is the interface of)
Anyway, that finishes convincing me fixing that video priority issue is difficult and the tools aren't easy to use (or working) to do the fixes, so I consider I've gone far enough and am giving up and not looking into this issue anymore.
Thanks a lot for the information and input however, I'm very happy to have learnt a few things and will remember to come back here if for some reason I REALLY have to try to find a solution.
Once hostapd in OpenWrt supports this feature out of the box, it should be relatively easy. In the mean time, you can use iptables to retag traffic with DSCP EF to DSCP CS6 which will put it into WMM voice queue.
it's not that hard. Is this Archer C7 running as an AP or as your main router?
# QoS Map Set configuration
# Comma delimited QoS Map Set in decimal values
# (see IEEE Std 802.11-2012, 18.104.22.168)
# [<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.
# default: not set
so that would probably mean something like:
to move DSCP 46 aka EF into UP6 aka AC_VO, DSCP 8 aka CS1 into UP1 aka AC_BK, and all the rest into UP0 aka AC_BE, not sure whether that works that will work any better...
I guess, I need to test it with master and 19.07.0 (which upgrades to hostapd 2.9), but I fear that it might simply be not configured in OpenWrt to save space. Time to see whether I can easily change that for a private build...
Sure it should have been
46,6,0,7,8,8,9,63,255,255, 255,255, 255,255, 46,46, 255,255
The goal really is to only move 46 to EF for testing, and keep everything else <= AC_BE, so the gap in AC_VI was intentional. This was not intended as a proposal for a final mapping but just enough to be able to use
It looked so easy, just uncomment CONFIG_INTERWORKING=y in
# Interworking (IEEE 802.11u)
# This can be used to enable functionality to improve interworking with
# external networks (GAS/ANQP to learn more about the networks and network
# selection based on available credentials).
But alas this runs into a compile error and I run out of time....
I've gotten it to compile by setting CONFIG_INTERWORKING=y and CONFIG_HS20=y in hostapd-full.config and wpa-supplicant-full.config. In my build I selected wpad-openssl and hostapd-utils. So far I have done the following:
root@telia:~# hostapd_cli -i wlan0 set_qos_map_set 0,63,255,255,255,255,255,255,
root@telia:~# hostapd_cli -i wlan1 set_qos_map_set 0,63,255,255,255,255,255,255,
I haven't verified that it actually works, but the output is encouraging.