From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id BF7C921F382; Fri, 20 Mar 2015 08:39:19 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YYz13-0003qE-Jq; Fri, 20 Mar 2015 16:39:17 +0100 Received: from m91-131-88-186.cust.tele2.no ([91.131.88.186]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1YYz11-0003qE-TN; Fri, 20 Mar 2015 16:39:17 +0100 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> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-C3D38418-52E3-468F-BBC7-6A2207856054 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: Michael Welzl Date: Fri, 20 Mar 2015 16:39:11 +0100 To: Jim Gettys X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 4 sum rcpts/h 18 sum msgs/h 7 total rcpts 26659 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1E77018DB9FDEE673B80C6B2A1632F7E13B64BAF X-UiO-SPAM-Test: remote_host: 91.131.88.186 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 3 max/h 3 blacklist 0 greylist 0 ratelimit 0 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:39:48 -0000 --Apple-Mail-C3D38418-52E3-468F-BBC7-6A2207856054 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On 20. mars 2015, at 16:31, Jim Gettys wrote: >=20 >=20 >=20 >> On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl wrot= e: >> Folks, >>=20 >> I think I have just seen this statement a little too often: >>=20 >> > 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. P= eople have been trained to believe that any packet loss is terrible (..) >>=20 >> 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 c= omes 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 b= locking delay on the receiver side: at least with TCP, whatever has been rec= eived after a dropped packet needs to wait in the OS for the hole to be fill= ed before it can be handed over to the application. >>=20 >> Here we're not talking a few ms more or less in the queue, we're talking a= n RTT, when enough DupACKs are produced to make the sender clock out the mis= sing packet again. Else, we're talking an RTO, which can be much, much more t= han an RTT, and which is what TLP tries to fix (but TLP's timer is also 2 RT= Ts - so this is all about delay at RTT-and-higher magnitudes). >>=20 >> Again, significant delay can come from dropped packets - you just don't s= ee it when all you measure is the queue. ECN can help. >=20 > =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 lo= sses anyway, as the bloated queues overflow. >=20 not necessarily with ecn. and where in a burst loss occurs also matters > So without AQM, you are =E2=80=8Boften/usually in much, much, much worse s= hape; better to suffer the loss, and do the retransmit than wait forever. sure!! > - Jim >=20 >>=20 >> Cheers, >> Michael >=20 --Apple-Mail-C3D38418-52E3-468F-BBC7-6A2207856054 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On 20. mars 2015, at 16:31, Jim Gettys <jg@freedesktop.org> wrote:



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=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. P= eople have been trained to believe that any packet loss is terrible (..)
=
I understand the "wrong mindset" thing and the idea of AQM doing something b= etter. Still, I'd like people to understand that packet loss often also come= s with delay - for having to retransmit. This delay is not visible in the qu= eue, but it's visible in the end system. It also comes with head-of-line blo= cking delay on the receiver side: at least with TCP, whatever has been recei= ved 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 R= TT, when enough DupACKs are produced to make the sender clock out the missin= g packet again. Else, we're talking an RTO, which can be much, much more tha= n 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 i= t when all you measure is the queue. ECN can help.

=
=E2=80=8BAnd without AQM, the RTT's are often many times the actual spe= ed of light RTT's, sometimes measured in seconds.  And you eventually g= et the losses anyway, as the bloated queues overflow.

=

not necessarily with ecn. and where i= n a burst loss occurs also matters


So without= AQM, you are =E2=80=8Boften/usually in much, much, much worse shape; better= to suffer the loss, and do the retransmit than wait forever.

sure!!

=

                &nb= sp;                     &n= bsp;      -  Jim


Cheers,
Michael


= --Apple-Mail-C3D38418-52E3-468F-BBC7-6A2207856054--