From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E326F3B2BE for ; Wed, 6 Apr 2016 12:08:35 -0400 (EDT) Received: by mail-ig0-x231.google.com with SMTP id f1so133589568igr.1 for ; Wed, 06 Apr 2016 09:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=edmison-net.20150623.gappssmtp.com; s=20150623; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=i1/TqdLWV/FrI27iYD2fvqGzxhkBqxE6+ByUXyW7Lzg=; b=vMMfB8ygHL9xKuI22tXwah6dm0Oeav7lwJIzbM8XHFo+OROH5t1HpABLOZtqeSSAqI 3+vp2D9EcFXau1wJF4LzkCDSEcv2alkeAn3Ik3wjEslusSu4LFz3p4EG1gPxU/DgXdqd oHd2NBJJZoqqX6mcFdsK63t5DHb2UJIhw5RMaaR4y1zpqxNbbdVSOJP9GFR81muwCKYB a8ebHKaL9tSQ71fJFF1pSpE4FKO23J361EcGHyjLBpOkBHJufH9NcUwuJzzttnWWjMBB cpuJvuFzOwFs1ID/cVvb9kgMdEf9hTKr3IdmO78HgIM2q4aAc25lJocMgA2iUda+uBNe bVJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=i1/TqdLWV/FrI27iYD2fvqGzxhkBqxE6+ByUXyW7Lzg=; b=WyXWHaBmU6wEFPVX6PLZAtNXhg4+/Kx9IpwRlelIH0ZUBIxmk9tGfZgowPgPS7nMIY 5WKtD7+E4nkfvMbWkqOD470RWyWbT6C31nHh7Yrkyi7GPoup+9LwYp0pu31qRTLugt5O pw6xpAZD4RUpZEOH32rYMQMjoTT0A/PnJNZjjEHTzduatzEA9CdQRZgVvG746suCz9fj g48KeAI+7YhJTTcDlcDybbx9iCZPhNJGcxNWRVLdNpAYucbHdImZ8SH94w+d6saaSi0A 2pHvolx4YcW8hS82dUpcO6oMLc6wpYSiPOrAEo+m3L4612r5x2EPM54qQ/ZWvL6YvXVE dc0w== X-Gm-Message-State: AD7BkJJ2FTvnQ6qO48G1wnqq0i/XOquP5k9duENYs5Lnwv4wWQxr28io0kFIFoKVHprOqw== X-Received: by 10.50.13.9 with SMTP id d9mr3150852igc.36.1459958915222; Wed, 06 Apr 2016 09:08:35 -0700 (PDT) Received: from [135.121.253.111] ([72.1.196.178]) by smtp.gmail.com with ESMTPSA id a75sm1712259ioj.36.2016.04.06.09.08.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 09:08:34 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Cc: jb , bloat X-Mailer: iPhone Mail (13E238) From: Kelvin Edmison Date: Wed, 6 Apr 2016 12:08:33 -0400 To: Dave Taht Subject: Re: [Bloat] dslreports bufferbloat tests X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 16:08:36 -0000 I think people focus on packet loss so much because the term is short, seemi= ngly conveys a lot of info and is easy to measure.=20 Given that know how to measure bloat, it strikes me that what is needed is a= short marketing-style tag for bloat that can be put up against the term "pa= cket loss".=20 To kick off discussion, I'd suggest 'latency hit'. As in, man, I took a big l= atency hit when trying to get to zero packet loss. If it's measured as mil= liseconds of delay above the minimum possible when buffers are empty, then w= e can start to get testers to test and publish results in both dimensions an= d start to drive discussion and awareness of how a little packet loss can dr= ive your latency hit way down.=20 Regards, Kelvin=20 Sent from my iPhone > On Apr 6, 2016, at 11:30 AM, Dave Taht wrote: >=20 >> On Tue, Apr 5, 2016 at 8:19 PM, jb wrote: >> I take your point regarding Quality >=20 > Thx! I am not grumpy at you in particular, but at a world that > continues to view packet loss as completely undesirable (I was at > several ietf meetings like that yesterday, and 2 days ago the > FCC's "nutrition labels for broadband" got a lot of press: > http://arstechnica.com/business/2016/04/fccs-nutrition-labels-for-broadban= d-show-speed-caps-and-hidden-fees/ > ) >=20 > Does anyone know how these nutrition labels are calculated? >=20 >> but both your examples in the post show A+ quality? >=20 > Well, yes... :) I did both of those with ecn on. (I did also get an A+ > with ecn off) >=20 > "desirable" packet loss, varies based on the number of flows, the > targetted queuing delay, the bandwidth of the link, the tcp, and the > RTT. It rapidly drops into the low percentage points for this > particular test,for those particular parameters. >=20 > as for: >=20 > "Quality Grades >=20 > Quality refers to average detected packet loss / re-transmit > percentages during download phase. The higher the packet loss / > re-transmit percentage the more inefficient the connection is, and a > very poor result may be indicative of congestion, inside wiring issues > or other problems that need addressing. >=20 > "1% or less - A+ > 2.5% or less - A > 3% or less - B > 5% or less - C > 12% or less - D > over 12% - F" >=20 > What I specifically objected to was this formula for calculating the > grade. After stewing about it a while (um, er, *years*, now), I > realized last night that with a little work, now that we know what > aqms such as pie and fq_codel can achieve, that we could, indeed, get > a desirable range of "packet loss" for X flows, Y RTT, and Z > bandwidth. >=20 > btw: Does your test have the ability to track "CE" marks? That would > be like a "gold star" affixed to the test report. (latest IoS has some > support for ecn now by default) >=20 >> I'm thinking that packet loss significant enough to show as a "C" or >> worse is mostly a bad situation >=20 > I pointed at a case where 25% packet loss was good here. >=20 > http://localhost:1313/post/rtt_fair_on_wifi/ >=20 > I am tempted to build on this theme, because it is not intuitive that > desirable loss is a curve - a lot at low rates, but at higher rates, > much less loss occurs and and really high rates one loss hurts... >=20 >> even if avoiding all packet loss - by using huge buffers - is >> definitely a disaster.. >=20 > Yes. 0 and major bufferbloat would be an F grade for me, for "Quality" :) >=20 > In other news, I sure wish the cable modems out there had followed > these guidelines at least. >=20 > http://www.cablelabs.com/wp-content/uploads/specdocs/CM-GL-Buffer-V01-1109= 15.pdf >=20 >>=20 >>=20 >>> On Wed, Apr 6, 2016 at 12:21 PM, Dave Taht wrote: >>>> On Tue, Apr 5, 2016 at 6:33 PM, Brandon Applegate wr= ote: >>>>=20 >>>>> On Apr 5, 2016, at 9:04 PM, Dave Taht wrote: >>>>>=20 >>>>> Does anyone know what the "quality" portion of dslreport's metric mean= s? >>>>=20 >>>> Basically - packet loss. >>>>=20 >>>> https://www.dslreports.com/faq/17930 >>>=20 >>> Sigh. I ranted. I might rant harder. >>>=20 >>> http://blog.cerowrt.org/post/bufferbloat_vs_quality/ >>>=20 >>>>=20 >>>> =E2=80=94 >>>> Quality Grades >>>>=20 >>>> Quality refers to average detected packet loss / re-transmit percentage= s during download phase. The higher the packet loss / re-transmit percentage= the more inefficient the connection is, and a very poor result may be indic= ative of congestion, inside wiring issues or other problems that need addres= sing. >>>>=20 >>>> 1% or less - A+ >>>> 2.5% or less - A >>>> 3% or less - B >>>> 5% or less - C >>>> 12% or less - D >>>> over 12% - F >>>> =E2=80=94 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Bloat mailing list >>>> Bloat@lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/bloat >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat