From: Kelvin Edmison <kelvin@edmison.net>
To: Dave Taht <dave.taht@gmail.com>
Cc: jb <justinbeech@gmail.com>, bloat <Bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] dslreports bufferbloat tests
Date: Wed, 6 Apr 2016 12:08:33 -0400 [thread overview]
Message-ID: <F6266EE9-3024-4C68-ADB1-52ADB288595A@edmison.net> (raw)
In-Reply-To: <CAA93jw4MDY16x3-e6bdejdiT1AC_KMUg=fEd+BDU=RL3ZARsrg@mail.gmail.com>
I think people focus on packet loss so much because the term is short, seemingly conveys a lot of info and is easy to measure.
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 "packet loss".
To kick off discussion, I'd suggest 'latency hit'. As in, man, I took a big latency hit when trying to get to zero packet loss. If it's measured as milliseconds of delay above the minimum possible when buffers are empty, then we can start to get testers to test and publish results in both dimensions and start to drive discussion and awareness of how a little packet loss can drive your latency hit way down.
Regards,
Kelvin
Sent from my iPhone
> On Apr 6, 2016, at 11:30 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
>> On Tue, Apr 5, 2016 at 8:19 PM, jb <justinbeech@gmail.com> 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-broadband-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-110915.pdf
>
>>
>>
>>> On Wed, Apr 6, 2016 at 12:21 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>> On Tue, Apr 5, 2016 at 6:33 PM, Brandon Applegate <brandon@burn.net> wrote:
>>>>
>>>>> On Apr 5, 2016, at 9:04 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>
>>>>> Does anyone know what the "quality" portion of dslreport's metric means?
>>>>
>>>> Basically - packet loss.
>>>>
>>>> https://www.dslreports.com/faq/17930
>>>
>>> Sigh. I ranted. I might rant harder.
>>>
>>> http://blog.cerowrt.org/post/bufferbloat_vs_quality/
>>>
>>>>
>>>> —
>>>> 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
>>>> —
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
next prev parent reply other threads:[~2016-04-06 16:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 1:04 Dave Taht
2016-04-06 1:33 ` Brandon Applegate
2016-04-06 2:21 ` Dave Taht
2016-04-06 3:19 ` jb
2016-04-06 15:30 ` Dave Taht
2016-04-06 16:08 ` Kelvin Edmison [this message]
2016-04-07 18:13 ` Livingood, Jason
2016-04-07 18:23 ` Livingood, Jason
2016-04-20 6:06 ` jb
2016-04-20 6:10 ` Dave Taht
2016-04-20 12:43 ` Jonathan Morton
2016-04-20 22:53 ` jb
2016-04-21 2:22 ` Jonathan Morton
2016-04-07 2:06 ` jb
2016-04-07 2:14 ` Jonathan Morton
2016-04-07 18:16 ` Livingood, Jason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F6266EE9-3024-4C68-ADB1-52ADB288595A@edmison.net \
--to=kelvin@edmison.net \
--cc=Bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=justinbeech@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox