"Problem #2 is oversized queues everywhere else on the Internet. The truth is, for almost everyone reading this, you don't care even a little bit about problem #2"
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.
It's difficult to take advantage of ECN nowadays, too. Some ISPs seem to clobber the ECN field when packets enter their AS. This is measured and discussed here: http://dl.acm.org/citation.cfm?id=2068833. Notably:
"""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.
There's nothing the XP computer can do to fix that, as it is the victim of the delays and needs the cooperation of other hosts that are to some degree involved in causing the problem. As I understand it, ECN on the Mac enables the Mac to cooperate with queue management elsewhere (the Mac could be doing its own queue management without ECN, but probably doesn't). The Quake trouble indicates the bottleneck is an overlarge buffer on a router you both share. You need your shared router to do some queue management (CeroWrt is a good platform for this) so that large downloads don't increase delays for all connections. If your ISP modem has bloated buffers and you can't replace it, you may be entirely out of luck.
Surely the obvious cure is: start every connection using Vegas, detect unreasonable backoff and switch to Cubic. (In game theory: optimistic tit-for-tat.)
There are two problems with vegas: (1) it starves when competing with traditionally-aggressive TCP; and (2) earlier vegas flows can be outcompeted by later vegas flows, so it isn't fair when competing against itself. The problem is that the earlier flows can cause a queueing delay which is detected by the later flow as a larger base RTT; the earlier flows have self-tuned to back off above a smaller RTT, so they behave less aggressively than the later flows.
This strategy would be no worse than the status quo for those connections, you'd still end up using Cubic.
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.
good article, although i concur with his assertion that the acm interviewees only want to tackle "fix the internet". jim gettys has been pretty active in the cerowrt project, which is a home router firmware, not coincidentally initiated by him.
I'll stick with CurveCP, thanks. It works, it has the added "perk" of encryption, and it's not tied to a single application, like uTP.
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.
If there was a generic utpclient/utpserver pair of applications that I could use to proxy non-uTP applications, as there is with CCP, I'd try using uTP/LEDBAT. But to my knowledge, there isn't.
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.