<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On 20. mars 2015, at 16:31, Jim Gettys <<a href="mailto:jg@freedesktop.org">jg@freedesktop.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl <span dir="ltr"><<a href="mailto:michawe@ifi.uio.no" target="_blank">michawe@ifi.uio.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Folks,<br>
<br>
I think I have just seen this statement a little too often:<br>
<br>
> 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 (..)<br>
<br>
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.<br>
<br>
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).<br>
<br>
Again, significant delay can come from dropped packets - you just don't see it when all you measure is the queue. ECN can help.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">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.</div></div><div><div class="gmail_default" style="display:inline"><br></div></div></div></div></div></div></blockquote><div><br></div>not necessarily with ecn. and where in a burst loss occurs also matters<div><br></div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail_default" style="display:inline">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.</div></div></div></div></div></div></blockquote><div><br></div>sure!!</div><div><br></div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail_default" style="display:inline"> - Jim</div></div><div><div class="gmail_default" style="display:inline"><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Michael<br>
<br>
</blockquote></div><br></div></div>
</div></blockquote></div></body></html>