TCP doesn't suck, and all the proposed bufferbloat fixes are identical
apenwarr.ca
apenwarr.ca
Apenwarr is misreading Van Jacobson here. What VJ says is "data piles up wherever there's a fast-to-slow transition, and nowhere else". That's in your router upstream, but it's also in your ISP's router nearest to you, downstream. You can only fix one of these on your own, which is the reason for the 'alarmist' articles: to get ISPs to pay attention.
To enable it on Linux:
sudo sysctl net.ipv4.tcp_ecn=1
echo net.ipv4.tcp_ecn=1 |sudo tee /etc/sysctl.d/10-ecn.conf
"""Via large-scale path measurements, we find the ECN feedback loop failing in the core of the network 40% of the time, typically at AS boundaries."""
So, unfortunately, we've got a ways to go on this.
Possibly you'd have to hack up a netfilter rule.
It implements the “look at the time you've had a queue above threshold” bit.
But if by good luck you were only crossing paths with Vegas, you would both get a smoother ride. And as the strategy spread, that would happen more often.
That turns out to be a much more interesting question than I was thinking of when I wrote it out. Try searching for 'multi agent tit for tat'.
Then again, if you tie something into an application that hundreds of thousands of people already use, like uTP is tied into a popular bittorrent client, you can then claim "Hundreds of thousands of people are using it, to carry major traffic."
Of course, from the perspective of a Bittorrent client author it's much easier to implement TCP-over-UDP than to depend upon raw socket support / install a custom congestion control algorithm into the OSes TCP stack.