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

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

[leetminiwheat]

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

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

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 seems particularly useful for mobile devices and/or crowded
airspace, so I'd like to somehow get this working right.

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

[Dave Taht]

On Fri, Apr 17, 2015 at 11:06 PM, leetminiwheat <LeetMiniWheat@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@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

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

[leetminiwheat]

On Sat, Apr 18, 2015 at 2:57 AM, Dave Taht <dave.taht@gmail.com> wrote:

Thanks for the replies, very informative!

>> 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.

Are you sure mobile phones don't treat VO differently, such as
disabling more power savings features in order to handle VO packets
better? I did notice an improvement in a voice-chat app through the VI
queue but It's still not perfect. with PINGOPT=1 the device jitters
between 2ms-300ms with little to no traffic, 2ms-150ms with txqueuelen
16, but with constant downstream traffic it holds steady around 3ms.
My thinking was perhaps VO packets would keep it from doing tricks
with aggregation and causing delay and static in voice chat apps that
don't set their traffic properly to the client OS.


> 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.

Well I for one greatly appreciate all the work you and everyone else
has done to fix networking. I wouldn't hesitate to donate if I was in
a financial position to do so. Thanks again for the reply and for
clearing some things up that i was scratching my head over.

P.S. amazing stuff in your debloat script! though hard to read even
with a decent understanding of LUA. Can't seem to get it to change
txqueuelen though even after installing ethtool, fixing the path, and
appending FORCE_RING='tx 16' to hotplug/iface/00-debloat, but I've got
a custom init script at the end boot that does most of what I need. I
understand at this point (if time/finances were permitted) you'd be
working on chaos calmer which doesn't even use hotplug anymore
anyways.