3 ms·
> everyone can cheat, but almost no one does Try running a site with big files for downloads. Every week or so, you'll be visited by someone who runs 200+ simu
by Sesse__ 6y ago
> everyone can cheat, but almost no one does
Try running a site with big files for downloads. Every week or so, you'll be visited by someone who runs 200+ simultaneous connections for the same file, keeps opening more, and ignores HTTP errors (like “too busy”).
There are also the “IW wars”, where CDNs compete by increasing their initial window more and more to gain an edge. This will be exponentially worse with QUIC, when tuning these knobs becomes more accessible to non-experts.
- Animats 6y agoeveryone can cheat, but almost no one does That's the point of "fair queuing". The idea is that if you send too much, you just compete with your own packets, and thus are not rewarded for sending too much. This discourages hogging the bandwidth. But fair queuing is computationally expensive, and is rarely seen in core routers, where some FPGA is doing routing. It's also not seen enough in home routers, where fast LAN hits slower uplink and a FIFO queue gets long, increasing latency. That's "bufferbloat". Quite fixable. Now get AT&T and Comcast to cooperate. From the paper, "Classic congestion control questions on fairness guarantees and convergence need to be re-answered for the new rate-based congestion control paradigm." Yes. They're looking at performance for individual nodes. This will be exponentially worse with QUIC Or when Google uses it to improve their responsiveness vs. others?
- Sesse__ 6y agoThe point is that QUIC (and related efforts) is a library, not implemented in the kernel. This makes it way easier to deploy, but also way easier (in practice) to change in bad ways.
- youngtaff 6y agoCDNs also adapt the initcwnd based on the destination network the packets are being sent too