[toast0]

Fairness at the bottleneck is what matters.

I think the hope is that OS developers will continue to generally pursue (tcp) congestion control that is at least reasonably fair. But if it's under the control of app developers, there's less of a track record of doing the right thing.

Congestion management at bottlenecks is very hard at the bottleneck. If a 40gbps port is congested, the routers on that port almost certainly do not have the ability to do any sort of fair queue management. So everyone has to play nice.

It is not terribly hard for an app developer to get millions of installs; it's a lot harder for an app developer to get millions of patched kernels.

That said, if the whole deal with quic is google wanted userspace congestion control, which is understandable, I don't see why they didn't just do that. It's not like they don't control a large amount of servers with a ton of traffic, and they also control the OS (to some degree) on a large amount of clients. http/2 multiplexing would still be as obviously flawed as it was on release. You'd still have head of line blocking on http/2, but with the right settings, you can just have multiple tcp connections... TLS 1.3 0-RTT and maybe tcp fast open could get round trip counts reduced when appropriate. With proper congestion control, you could share the congestion context for multiple connectjons tk the same peer. QUIC would still have the upper hand with the ability to selectively not retry on unacknowledged data, but I don't know how often that's really used.