Hacker News Reader

Comment by quotemstr | Hacker News Reader

QUIC is technically excellent. I have a game-theoretic concern with putting it in userspace.

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.

View on HN

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.

Also, couldn't the OS still throttle back greedy applications? No reason it couldn't detect the heavy stream of UDP traffic.

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.

> 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

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

I'm having a bit of trouble understanding your point. Perhaps you could give a specific example of what you mean by "ever-more-aggressive flows?"

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?

In HTTPS, nobody. Else, proxies ?

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)

Clients' kernels?

Reply on news.ycombinator.com