[Bloat] dslreports bufferbloat tests

[Dave Taht]

On Tue, Apr 5, 2016 at 8:19 PM, jb <justinbeech at 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 at gmail.com> wrote:
>> On Tue, Apr 5, 2016 at 6:33 PM, Brandon Applegate <brandon at burn.net> wrote:
>>>
>>>> On Apr 5, 2016, at 9:04 PM, Dave Taht <dave.taht at 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 at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat