[Cerowrt-devel] ath9k WMM not obeying DSCP/TOS flags?

[Dave Taht]

On Fri, Apr 17, 2015 at 11:06 PM, leetminiwheat <LeetMiniWheat at gmail.com> wrote:
> I've tried, to no avail, to get certain traffic to go to the BK and VO
> queues via DSCP and/or TOS mangling (with HTB+fq_codel egress/ingress
> DSCP stripping/squashing turned OFF, i.e. flags enabled).

The VO queue is disabled in cerowrt in favor of better aggregating
those sorts of packets into the VI queue.

>
> Is this a known issue? Or intentional behavior? Or something
> misconfigured in qdiscs? Shoving tons of traffic down wifi which
> should be DSCP/TOS flagged for BK or VO only puts it in VI or BE from
> what I can tell from /sys/kernel/debug/ieee80211/phy0/ath9k/queues and
> /sys/kernel/debug/ieee80211/phy1/ath9k/queues

CS1 should land in BK, as best as I recall.

> I've tried -j DSCP --set-dscp xxx in mangle PRE/POST and I see the
> MARKing going on in QOS_MARK_$IFACE zone(s), so the traffic is clearly
> getting marked for QoS bins
>
> A wireless "expert" friend of mine was saying a lot of WMM issues
> weren't fixed until kernel 3.17-3.18?

WMM is basically broken, conceptually, since the arrival of wireless-n and
the existing structure of the wifi queue drivers in linux.

See mit talk here, 2nd half:

https://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be

> WMM seems particularly useful for mobile devices and/or crowded
> airspace, so I'd like to somehow get this working right.

No it is not useful for crowded airspace, unless you are trying for a temporary
game theory win over everyone else that is not using wmm.

I have long documented the ills of the VO queue in general in benchmarks
and documentation on how it interacts badly with aggregation. As for
using the BK queue effectively, a common problem is that much traffic
is mis-marked as CS1 that should not be. I don´t recall disabling it in
the stable release of cerowrt, nor did I attempt to push the patch up
to openwrt, so openwrt probably continues to (mis)use the VO queue.

In general, you do best by minimizing TXOPs and maximizing aggregation
in crowded wifi environments.

It is not "fixed" in any current kernel. Although it may be working
better "as specified" in current kernels, the spec is basically wrong.

We do propose a set of fixes in
make-wifi-fast that will promote or demote aggregates to a more
appropriate wmm queue when enabled. This is partially laid out in pp 26-

http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-0wng-More-on-Bufferbloat.pdf

One of these days we will get around to writing a paper on this,
but I thought it would be best to focus on fixing it, first, then
showing the differences with wifi behavior in real environments after,
in particular, we get per station queues working with minstrel-blues.

Gaining the resources to fix wifi has eaten most of the last 10 months
of my life, AFTER helping come up with some of the theoretical fixes
over the last 4 years. We are finally in a position to make a run at
making deployable some of the same latency reducing techniques we have
successfully applied to wired links to wifi, but MUCH work remains,
and nearly zero funding exists, still. I had honestly hoped to be able
to fully prototype and test the fixes over the summer, but that hope
fades more and more every day.

> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67