From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 AA0113B337 for ; Wed, 6 Apr 2016 22:06:57 -0400 (EDT) Received: by mail-ig0-x229.google.com with SMTP id f1so143686447igr.1 for ; Wed, 06 Apr 2016 19:06:57 -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-transfer-encoding; bh=SLxLkZNkifP+0h6D1aY0N3sTDOj8m8BH3Rfe532C9Sk=; b=Q6s4FT7L5K8JEV3u55s1a7eJBLuc5mmI0hq+//KdyEraWe3hboLnb7kkRdtMhXonN5 M9E+zZeIw6+wRZo7vPR3/WOFqUxox/uWs8pS/jahre0FsEf/YkZndiVOPwFBqzM4X4Io 4XCKCwZJBON36HbakmEUGTEGnug4lmY1SseeXxWnviu8sXRZmchebfsCKFIAxBYcmBQO OeDaME69nJe3uJLkCpkQKSAfFc+kNTNnZbtNNgDi5iVQwHCnm1eepxBRlUPU/wRz2NoP AqrfHJkli7j5qLfYx4FPCDBXPcuBjwbwmaIIjV9gwyBQllk+14R/xX7pH6xwJDR6SeV0 +Psw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=SLxLkZNkifP+0h6D1aY0N3sTDOj8m8BH3Rfe532C9Sk=; b=aHlFK6CNNlRdfHqbe10CjmwiEqkmU+d92b7wqd2QtTTI7+wlxqqiOFGAIes6eqgFGk Cuw8ACzU7SrWOuj+a9Fe4JpOxm7JqM6pKcXYpj02qWxJWvrrvGF1Ix+yjT1ecSAvsyis saSIwtLrxQQeqhgaashaIURBoFMxcrG+tzA3sj+KittWway9rEYgrMSBCOuDXMOi1qLp IK/9S9GWEgW+WKonHCmwDJpMA0RY2f9lYPrW5JzU+Y7vkH1koUttCfZzdQBoM8SSE2TO gft2j9dR0pJkqAVba85Qxef8SuUmGhmC34jEI/8LCNgwZLSU20Jkwz0JTs5qwGxr1R5v cfBw== X-Gm-Message-State: AD7BkJKfRNqgxeIBGmMKuyvLohMCofpO++BkjHO/79s4lshSkqzJp2uMNHV7W6MdkGG1jnGGzf1sKWr3+MKOEQ== MIME-Version: 1.0 X-Received: by 10.50.47.82 with SMTP id b18mr917543ign.41.1459994817138; Wed, 06 Apr 2016 19:06:57 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.178.102 with HTTP; Wed, 6 Apr 2016 19:06:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Apr 2016 12:06:57 +1000 X-Google-Sender-Auth: 4AcM31mTChgawxi4HoBQgjnx1UU Message-ID: From: jb To: Dave Taht Cc: Brandon Applegate , bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 07 Apr 2016 02:06:57 -0000 Regarding picking up advanced congestion management in a result, it would be possible by adding a concurrent tcpdump on each test server - running all the time and filtering for the appropriate bits. But am I just looking for "ECN capable" flags originating from a given public IP? or am I filtering just for CE marks (11), indicating there was some active queue management actually going on -- and only that would be worth mentioning? thanks On Thu, Apr 7, 2016 at 1:30 AM, Dave Taht wrote: > On Tue, Apr 5, 2016 at 8:19 PM, jb wrote: >> I take your point regarding Quality > > 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-broadba= nd-show-speed-caps-and-hidden-fees/ > ) > > Does anyone know how these nutrition labels are calculated? > >> but both your examples in the post show A+ quality? > > Well, yes... :) I did both of those with ecn on. (I did also get an A+ > with ecn off) > > "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. > > as for: > > "Quality Grades > > 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. > > "1% or less - A+ > 2.5% or less - A > 3% or less - B > 5% or less - C > 12% or less - D > over 12% - F" > > 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. > > 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) > >> I'm thinking that packet loss significant enough to show as a "C" or >> worse is mostly a bad situation > > I pointed at a case where 25% packet loss was good here. > > http://localhost:1313/post/rtt_fair_on_wifi/ > > 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... > >> even if avoiding all packet loss - by using huge buffers - is >> definitely a disaster.. > > Yes. 0 and major bufferbloat would be an F grade for me, for "Quality" :) > > In other news, I sure wish the cable modems out there had followed > these guidelines at least. > > http://www.cablelabs.com/wp-content/uploads/specdocs/CM-GL-Buffer-V01-110= 915.pdf > >> >> >> 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: >>>> >>>>> On Apr 5, 2016, at 9:04 PM, Dave Taht wrote: >>>>> >>>>> Does anyone know what the "quality" portion of dslreport's metric mea= ns? >>>> >>>> Basically - packet loss. >>>> >>>> https://www.dslreports.com/faq/17930 >>> >>> Sigh. I ranted. I might rant harder. >>> >>> http://blog.cerowrt.org/post/bufferbloat_vs_quality/ >>> >>>> >>>> =E2=80=94 >>>> Quality Grades >>>> >>>> Quality refers to average detected packet loss / re-transmit percentag= es during download phase. The higher the packet loss / re-transmit percenta= ge the more inefficient the connection is, and a very poor result may be in= dicative of congestion, inside wiring issues or other problems that need ad= dressing. >>>> >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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