3 ms·
They may all be affected, but with selective ACK that means the receiver will still ACK most of the data, the server will notice that one packet was missing via
by the8472 7y ago
They may all be affected, but with selective ACK that means the receiver will still ACK most of the data, the server will notice that one packet was missing via SACK, resend it along with even more new data and all you got is a larger batch coming in 1RTT later, throughput isn't affected if your congestion controller can distinguish spurious losses from congestion (as BBR does). The problem only snowballs when future requests will only be made depending on previous data.
- mnarayan01 7y agoThe other requests are still taking the latency hit.
- the8472 7y agoSure, but they were parallel requests in the first place, so in terms of wall time you're still only taking the latency hit once. And if they're larger in aggregate than the connection's BDP some of them would only have finished by the time that it has recovered from the loss anyway. So... it's complicated. I'm not saying that HoL is a non-issue and that TCP is perfect. It's just that you're not eating the latency penalty N times and for anything that is dominated by throughput rather than latency it's even less relevant.