
TCP small queues and WiFi aggregation – a war story - signa11
https://lwn.net/Articles/757643/
======
kev009
I've worked on TCP full time for a couple years and have to say, the more I
learn the more WiFi intimidates the heck out of me. I'm barely smart enough to
work on wired connections, and think RF DSP is largely beyond my faculties.
There's so much going on down there, and the cards are starting to become
effectively what we used to call TCP Offload Engines which is unfortunate. The
perceived benefit is lower power usage and optimization by RF-aware companies
but the negatives are pretty obvious to me. This means that changes like this
to mac80211 code (or moral equiv in other OSes) will be increasingly bypassed
and done in opaque closed firmware.

------
r1ch
I wonder what the real-world impact of this regression is as I'm sure there
are plenty of IOT devices out there that are running the affected Linux
versions. As the issue likely only manifests at higher bandwidths, I guess
things like wireless IP cameras or Wifi attached NAS would be the most
affected.

~~~
Const-me
WiFi cameras don’t send that much data, WiFi quality varies based on distance
to AP and radio interference. Also WiFi is often slower. A camera that streams
50 mbit/sec or more would be completely broken on any 802.11g 54 mbit/sec
network.

NAS-es are better example; they are often bandwidth bound. My guess is, users
are typically connecting them with a cable. Most clients are wireless these
days (e.g. I happen to type this on a wifi connected laptop), so doing 2 radio
hops, NAS-router and router-client, isn’t good for performance: both data
streams are competing for the same radio frequencies.

~~~
jws
The afflicted Linux devices will be spoiling the commons, even if they can
still get their own data sent without stalling.

Instead of combining frames for more efficient use of the available wireless
channel they will be sending an individual frame per packet and degrading the
total useful capacity of the channel. Wikipedia asserts in its WiFi frame
aggregation article that the overhead of a packet can be greater than the
actual data of the packet on high speed WiFi.

~~~
wtallis
The afflicted devices definitely make much worse usage of their airtime, but
do they actually end up getting much more total airtime/TXOPs? The stations in
question are definitely their own worst victim, and the impact they have on
competing stations could be far smaller.

------
westbywest
Looks like OpenWRT snapshot versions since Nov/Dev 2017, and now their
18.06-rc1, should have this incorporated.
[https://github.com/openwrt/openwrt/blob/a367645f23d2ed93ea29...](https://github.com/openwrt/openwrt/blob/a367645f23d2ed93ea29c7237fa1b2d6c3ded7e4/package/kernel/mac80211/patches/140-tweak-
TSQ-setting.patch)

~~~
wtallis
It doesn't help much to deploy this to routers, since they aren't endpoints
for much TCP traffic volume. Smartphones, laptops and other Linux-based client
devices are what need this fix the most.

------
equalunique
I feel as though the spirit of this article fits very well with the "hacker"
ethos appropriate for HN.

------
azinman2
How was this only recently addressed? WiFi transmission rates should be a
commonly seen problem?

~~~
wtallis
It takes some skill to figure out that your throughput is significantly lower
than the actual radio transmission rate. There are a lot of factors that can
hurt WiFi performance, and ruling out poor signal strength and interference
isn't easy for most users.

~~~
vvanders
Yup, we had a microwave that will happily take out Wifi in a 200' radius.

Every time I go through a drivethrough there's a 70% probability that my
2-meter radios breaks squelch even though I've only got it tuned to licensed
amateur bands.

Long way of saying that RF is hard and amazing it works as well as it does.

------
esaym
Anyone know if this was backported to older kernels?

~~~
danmg
No. It requires changes that were added late last year to the BBR scheduler.

