Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation?

[Jim Gettys <jg@freedesktop.org>]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl <michawe@ifi.uio.no> 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.

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.
                                             -  Jim


> Cheers,
> Michael
>
>

[-- Attachment #2: Type: text/html, Size: 2748 bytes --]