> Apps have been free to abuse UDP all this time, but it's not been a real issue. Even data-hungry applications like video-streaming have gone with TCP almost every time.

In the past Bittorrent and the creation of the µTP prooved ( http://blog.bittorrent.com/2009/11/13/testing-%C2%B5tp-is-%C... ) that unmanaged protocol abuse in userspace can lead to big degradation in QOS yes. Mainly due to "unfair" congestion policy between protocols.

> Apps have been free to abuse UDP all this time, but it's not been a real issue. Even data-hungry applications like video-streaming have gone with TCP almost every time.

I suspect that's more down to NAT than anything else

I worry that it'll become easier (and this more common) in an all QUIC world. It's always been possible, but few people have had the expertise and motive.

The OS can throttle sends on a single machine, but it can't arbitrate across machines or do anything about incoming flows.

> The OS can throttle sends on a single machine, but it can't arbitrate across machines or do anything about incoming flows.

Isn't that the case with TCP's congestion control as well? If the server's kernel isn't backing off properly, how can the client's TCP stack mitigate that?

People running services can and do play games with TCP send-side congestion control: see https://news.ycombinator.com/item?id=1942442

So far, these hacks have been limited by the need to work with stock receive-side TCP stacks. Once you move to UDP, all bets are off.