5 ms·
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 congest
by quotemstr 8y ago
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.
- nathanaldensr 8y agoI'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?"
- quotemstr 8y agoSay 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.
- unilynx 8y agoWhat is stopping you from doing this with TCP?
- ldng 8y agoIn HTTPS, nobody. Else, proxies ?
- Confiks 8y agoIt 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.
- unilynx 8y agoThe 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)
- deleted 8y ago[deleted]
- javajammer 8y agoClients' kernels?
- MaxBarraclough 8y agoApps 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.
- quotemstr 8y agoI 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.
- profmonocle 8y ago> 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?
- quotemstr 8y agoPeople running services can and do play games with TCP send-side congestion control: see https://news.ycombinator.com/item?id=1942442 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.
- M2Ys4U 8y ago> 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
- deleted 8y ago[deleted]