Folks, I think I have just seen this statement a little too often:
> That’s right, Jim. The “some packet loss is good” part is from what I have > seen the hardest thing for people to understand. People have been trained to > believe that any packet loss is terrible (..) I understand the "wrong mindset" thing and the idea of AQM doing something better. Still, I'd like people to understand that packet loss often also comes with delay - for having to retransmit. This delay is not visible in the queue, but it's visible in the end system. It also comes with head-of-line blocking delay on the receiver side: at least with TCP, whatever has been received after a dropped packet needs to wait in the OS for the hole to be filled before it can be handed over to the application. Here we're not talking a few ms more or less in the queue, we're talking an RTT, when enough DupACKs are produced to make the sender clock out the missing packet again. Else, we're talking an RTO, which can be much, much more than an RTT, and which is what TLP tries to fix (but TLP's timer is also 2 RTTs - so this is all about delay at RTT-and-higher magnitudes). Again, significant delay can come from dropped packets - you just don't see it when all you measure is the queue. ECN can help. Cheers, Michael _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
