Sent from my iPhone

> On 20. mars 2015, at 16:31, Jim Gettys <[email protected]> wrote:
> 
> 
> 
>> On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl <[email protected]> wrote:
>> 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.
> 
> ​And without AQM, the RTT's are often many times the actual speed of light 
> RTT's, sometimes measured in seconds.  And you eventually get the losses 
> anyway, as the bloated queues overflow.
> 

not necessarily with ecn. and where in a burst loss occurs also matters


> So without AQM, you are ​often/usually in much, much, much worse shape; 
> better to suffer the loss, and do the retransmit than wait forever.

sure!!


>                                              -  Jim
> 
>> 
>> Cheers,
>> Michael
> 
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat

Reply via email to