Also, couldn't the OS still throttle back greedy applications? No reason it couldn't detect the heavy stream of UDP traffic.
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.
I suspect that's more down to NAT than anything else
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?
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.
> 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.
(But even then, just open lots of TCP connections if you want to have your unfair share of bandwidth)
I worry that everyone will have an incentive to "cheat" at congestion control, leading to a tragedy-of-the-commons situation of ever-more-aggressive flows, followed by eventual congestion collapse.
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. But now that we're moving to a model in which applications do their own congestion control, an arms race seems inevitable.