Say I ship an app and control its backend servers. I control QUIC on both ends. What's stopping my using a non-standard QUIC that starts faster and that backs off less aggressively in response to congestion signals like delay and loss? If I do that and you don't, then on a congested link, my app will end up using more than its fair share of bandwidth.

What is stopping you from doing this with TCP?

It is addressed above:

> This effect didn't happen with in the TCP world, since most applications don't run with enough privileges to speak TCP without the kernel's involvement.

The argument is that while kernel developers wouldn't start this supposed "arms race", but application developers would.

I think we would have seen this already with things like (m)uTP if it was an issue.

The GP was talking about controlling both ends of the connection, I assumed that implied having root-level access to both ends. A scenario where you control both ends but don't have full TCP/IP stack access on at least one side seems pretty academical.

(But even then, just open lots of TCP connections if you want to have your unfair share of bandwidth)

In HTTPS, nobody. Else, proxies ?

Clients' kernels?