4 ms·

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?"

• quotemstr 8y ago
  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.
  • unilynx 8y ago
    What is stopping you from doing this with TCP?
    • ldng 8y ago
      In HTTPS, nobody. Else, proxies ?
    • Confiks 8y ago
      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.
      • unilynx 8y ago
        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)
    • deleted 8y ago
      [deleted]
    • javajammer 8y ago
      Clients' kernels?