[lxgr]

> QUIC’s design intentionally separates the wire protocol from the congestion control algorithm

Is that not the case for TCP as well? Most congestion control algorithms just assign new meanings to existing wire-level flags (e.g. duplicate ACKs), or even only change sender-side behavior.

> QUIC gives* control back to application developers to tailor congestion control to their use case*

That's what it actually does: It moves the congestion control implementation from the OS to user space.

In that sense, it's the same tradeoff as containers vs. regular binaries linking to shared libraries: Great if your applications are updated more often than your OS; not so great if it's the other way around.

[bayindirh]

> QUIC gives control back to application developers to tailor congestion control to their use case

If I understood modern application development correctly, this interprets as "The developers will import another library which they don't understand and will wreak havoc on other applications' data streams by only optimizing stuff for themselves".

Again, if I remember correctly, an OS is "the layer which manages the sharing of limited resources among many processes which requests/needs it", and the OS can do system-wide, per socket congestion control without any effort because of the vantage point it has over networking layer.

Assuming that every application will do congestion control correctly while not choking everyone else even unintentionally with user space's limited visibility is absurd at worst, and wishful thinking at best.

The whole ordeal is direct violation with application separation coming with protected mode.

[lxgr]

> Assuming that every application will do congestion control correctly while not choking everyone else even unintentionally with user space's limited visibility is absurd at worst, and wishful thinking at best.

Why? All practically used variants of TCP achieve fairness at the bottleneck without any central arbiter or explicit view of the upstream congestion situation. Besides, UDP has never had congestion control and has been around for decades.

> The whole ordeal is direct violation with application separation coming with protected mode. [...] The whole ordeal is direct violation with application separation coming with protected mode.

Are you concerned about fairness between applications on the same OS or fairness at the bottleneck, usually upstream from both application and OS/host?

In the former case, the OS always gets the last word, whether you're using TCP or your own homebrew congestion control via UDP, and you can make sure that each application gets the exact same fair egress rate if required. In the latter case, nothing prevents anyone from patching their kernel and running "unfair TCP" today.

[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.