3 ms·
A good question. Here is 2021 study: “Takeaway: We observe that QUIC provides significant improvements over TLS/TCP in low-bandwidth and high-RTT regions for v
by miohtama 4y ago
A good question. Here is 2021 study:
“Takeaway: We observe that QUIC provides significant improvements over TLS/TCP in low-bandwidth and high-RTT regions for video downloads. QUIC handshakes towards YouTube media servers offer an improvement of 534 ms (IN) and 406 ms (DE) when compared with TLS/TCP. We also observe that the overall download rate for TLS/TCP is higher than QUIC partly due to kernel optimizations such as LRO available for the TCP stack. QUIC provides a better video streaming experience with a lesser number and duration of stall events compared to TLS/TCP. We observe that TLS/TCP exhibits up to 50% longer stall durations compared to QUIC at 50th percentile for high loss networks.“
https://vaibhavbajpai.com/documents/papers/proceedings/quic-tnsm-2022.pdf https://vaibhavbajpai.com/documents/papers/proceedings/quic-...
Also the study discussed about the server-side CPU usage. If you are worried about server-side offloading, you can still stick to TCP/IP until the hardware acceleration and other offloading catches up.
- drewg123 4y agoI skimmed the paper, but I could not determine what TCP congestion control method they were testing against. Given the stall time, I expect that it was not BBR (which is the congestion control used by QUIC). If you improve TCP's congestion control and can also control the client TCP stack, most of BBR's advantages over TCP disappear.
- matsur 4y agoQUIC doesn't imply BBR as congestion control. eg. Our (Cloudflare's) QUIC implementation supports multiple algorithms. https://blog.cloudflare.com/cubic-and-hystart-support-in-quiche/ https://blog.cloudflare.com/cubic-and-hystart-support-in-qui...