Re: [Cerowrt-devel] [Make-wifi-fast] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e

[Sebastian Moeller <moeller0@gmx.de>]

Hi Jonathan, 


On July 30, 2015 11:56:23 PM GMT+02:00, Jonathan Morton <chromatix99@gmail.com> wrote:
>Hardware people tend to think in terms of simple priority queues, much
>like
>old fashioned military communications (see the original IP precedence
>spec). Higher priority thus gets higher throughput as well as lower
>latency.
>
>I note also that in 802.11e, leftover space in a TXOP can't be (or at
>least
>generally isn't) used opportunistically for traffic from another class,
>because the four queues are so rigidly separated.
>
>I think the hardware people are shortsighted in this respect. It's so
>easy
>to game simple priority queues when there's no filter on the field
>controlling it. That's why cake's Diffserv layer works the way it does.
>And
>if I ever get the chance to do a Wi-Fi specific version, I'll avoid
>both of
>the above problems.
>
>- Jonathan Morton

Thanks for the insight. Now I Start to realize why my jome network behaves AS it does. When I run RRUL locally from my macbook over WiFi with cerowrt as AP (which if I recall correctly only uses AC_BE) the macbook's send starves the AP and hence the macbook's receive tanks. Since macos seems to exercise the AC_v[I|o] queues, it hogs airtime and and all systems using lower AC classes see less airtime, less bandwidth and higher latency. I guess my gut feeling would be to run the AP always at AC_VO so it does not get starved. But really calling such a system where any station can inflict that much pain/badness on others 'quality of service' makes me wonder. Then again it certainly affects quality of service just not deterministic or overall positive ;)

Best Regards
       Sebastian
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.