4 ms·
I'm a fan of QUIC, but these articles are always heavy on explanations and light on data. I understand in theory how head-of-line blocking can cause serious iss
by apitman 3y ago
I'm a fan of QUIC, but these articles are always heavy on explanations and light on data. I understand in theory how head-of-line blocking can cause serious issues on a lossy network, but by this point I would expect to see a ton of data backing that up in real-world usage from Google and Cloudflare.
One specific question I've had is on a lossy network are there really that many situations where you would have packet loss on one QUIC stream but not most/all the others? I don't doubt that's true but I would love to see a breakdown.
Also, what's the crossover point between opening multiple TCP streams and doing round robin across them? Maybe you only need 3-4 TCP connections to estimate the HOL advantages of QUIC.
I will admit fewer RTT handshakes is a more obvious win.
- KMag 3y ago> One specific question I've had is on a lossy network are there really that many situations where you would have packet loss on one QUIC stream but not most/all the others? I don't doubt that's true but I would love to see a breakdown. If an intermediate router is using Randomized Early Detection (RED) and is congested within the randomized packed drop region, then you could easily see one random packet in the middle of a stream dropped, with other streams unaffected.
- adgjlsfhk1 3y ago> One specific question I've had is on a lossy network are there really that many situations where you would have packet loss on one QUIC stream but not most/all the others? This isn't the advantage. The advantage is that if you have 10 different streams and a low loss rate, the impact of each packet lost would be much smaller. Consider a voip call with an architecture where each person's audio is served as a separate stream from a central server. With head of line blocking, every packet lossed causes a slight stutter in the whole conversation because even if the lost packet is from someone not talking, you have to wait for that packet of silence before decoding the packet from the person speaking. With QUIC, the extra latency only affects the individual stream, so the conversation won't stutter when the person not talking wasn't the one who's packet got lost.
- apitman 3y agoWhat I'm questioning is how likely it is to lose a single packet on one stream. I understand why in theory that would be bad and QUIC would help, but I'm curious how often it actually happens. Sibling provided at least one example but I would be interested to see some data.