From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1290A21F382; Fri, 20 Mar 2015 08:31:28 -0700 (PDT) Received: by oiag65 with SMTP id g65so94020665oia.2; Fri, 20 Mar 2015 08:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dlwYj1Ue7VIQjsYkvvEk/1qoYQXdV918RQSv3sJwufM=; b=kf3knKRE6VIdnNKz2UEBr0NeyTj5Ga/KrY+jLmI8qnnqOY/roXzUlC9V3+9isES/tv xnHN2WpPNFhi928ltViY/5Cb4MDuJUGtWj4K3jIxaMsLQnwa3ACbZ39sInA2N0XTmftU CufpE52pL5mRqPhLuzpA1oWYJBvNbpo17ewvlsoZrjCHr31ANwY88qzzMBKDwCuc06eG j6lwoFi8QJaKcpVVOJoibbwcSyQh9FxQgXi/m2gFv0oiosplWD+YXanbRFd8Aime71ms hQd0IcBOdAI1JhWXexalFL+PdH4p/vu2s5aYB8dgacsXNJ2IVhoneXDF70DKCCiT3sT3 MIOw== MIME-Version: 1.0 X-Received: by 10.202.4.198 with SMTP id 189mr2303533oie.118.1426865487761; Fri, 20 Mar 2015 08:31:27 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.171.230 with HTTP; Fri, 20 Mar 2015 08:31:27 -0700 (PDT) In-Reply-To: References: <20150316203532.05BD21E2@taggart.lackof.org> <123130.1426635142@turing-police.cc.vt.edu> <15A0911A-E3B7-440A-A26B-C5E1489EA98B@viagenie.ca> <1426773234.362612992@apps.rackspace.com> Date: Fri, 20 Mar 2015 11:31:27 -0400 X-Google-Sender-Auth: 0FXk2gj9GSk_INiuGVJ9O-Ewqck Message-ID: From: Jim Gettys To: Michael Welzl Content-Type: multipart/alternative; boundary=001a11c036a48a59070511ba0275 Cc: "Livingood, Jason" , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [Bloat] DOCSIS 3+ recommendation? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 15:31:57 -0000 --001a11c036a48a59070511ba0275 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl wrote: > Folks, > > I think I have just seen this statement a little too often: > > > That=E2=80=99s right, Jim. The =E2=80=9Csome packet loss is good=E2=80= =9D 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 somethin= g > 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. > =E2=80=8BAnd without AQM, the RTT's are often many times the actual speed o= f light RTT's, sometimes measured in seconds. And you eventually get the losses anyway, as the bloated queues overflow. So without AQM, you are =E2=80=8Boften/usually in much, much, much worse sh= ape; better to suffer the loss, and do the retransmit than wait forever. - Jim > Cheers, > Michael > > --001a11c036a48a59070511ba0275 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Ma= r 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=E2=80=99s right, Jim. The =E2=80=9Csome packet loss is good=E2=80= =9D part is from what I have seen the hardest thing for people to understan= d. 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 f= or 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 ta= lking 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 muc= h, 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 magnit= udes).

Again, significant delay can come from dropped packets - you just don't= see it when all you measure is the queue. ECN can help.

=E2=80=8BAnd without AQM, the RTT's are often many times t= he actual speed of light RTT's, sometimes measured in seconds.=C2=A0 An= d you eventually get the losses anyway, as the bloated queues overflow.

So witho= ut AQM, you are =E2=80=8Boften/usually in much, much, much worse shape; bet= ter to suffer the loss, and do the retransmit than wait forever.
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- = =C2=A0Jim


Cheers,
Michael


--001a11c036a48a59070511ba0275--