thank you, esp for showing, in particular, how badly the BE queue performs under contention vs VI. BK oughta be worse! There is a lot of traffic mismarked as CS1 out there, in the vain hope that background actually means what L3 protocol designers meant as background, where 4seconds of delay with only one station on the case is well beyond what we meant as background. Trying to spit tcp through there, which has typical timeouts at 250ms, 1s and 2s essentially, means we end up sending more packets in a somewhat futile manner. If we could force upon application designers the idea that the BK queue might be delayed 10s of seconds, and restrict usage of it to just those apps, that would be great.
Back when we were thinking about 802.11e, the problem as then (2003!) seen was that VOIP really really really wanted a 10ms interval (now it's 20ms), we didn't have good jitter buffers, and ulaw and gsm encodings were the law of the land. So a limited number of VOIP phones on an AP worked better - ship it! (and again, this was a client, not as much AP, option at the time. The APs were supposed to figure out how to schedule responses, and many (enterprise) APs actually did do some of the right things here...
VI ended up as a bucket for where videoconferencing was to go. It seemed to make sense... to some...
but the complexities of 802.11e's bus arbitration don't make a lot of sense, period. IMHO.
After 802.11n showed up with aggregation which was vastly superior in terms of fitting packets into a txop (if you managed the queues right)... and atheros sold out to qcomm... most of the detailed AP knowledge began to fade from the field.
I turned off mappings via qos-map almost entirely (EF-only) years ago, and have in general not looked back. WMM is required that it work to pass the wifi alliance's tests! and thus it's on by default for nearly everybody else still, and the effect on real traffic, well... I'm in general thankful that so few applications have tried to use it to date. Used carefully from certain kinds of STAs still seems to be a decent idea. Note "carefully". There are a few wifi joystick-game controllers that use VI or VO....
Despite my opinion, I'd never got sufficient data from real world usage to convince enough people I was right.
With enough data, perhaps we can convince the openwrt folk to obsolete qos-map into the bk queue, at least. The VI queue isn't looking all that good either. Scheduling smartly, and intelligently reducing txop size under contention seemed the best strategy to me (in 2016)
I've sometimes hoped we could find another use for the 4 hardware queues. Or that they would work better in a mu-mimo situation. I keep hoping we find a benchmark that shows a demonstrable benefit for some form of real world traffic for the VI and VO queues for some generation of wifi.
I should probably note also that there are all sorts of other possible sources for observing the 4sec spikes on icmp seen here...
