Re: [Bloat] The "reasons" that bufferbloat isn't a problem

[Rich Brown <richb.hanover@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

I had an especially rewarding interaction on Reddit the other day. (
https://www.reddit.com/r/networking/comments/1d5dejy/bufferbloat_in_speed_tests_but_ping_doesnt_spike/
)

The initial message was a fellow was saying that speed tests were showing
bufferbloat, but his ISP said all was good. There were multiple
interchanges - here's a summary:

I started to say, "Maybe things are OK then..." and he said, "Well, I'm a
gamer, and bullet registration is off..."

So I asked for a Waveform test. In true non-believer fashion, he asked, "Is
it *possible* to have bufferbloat on X equipment?" I said I don't know -
run the test.

He did, and he did (have bufferbloat - a bit). I explained how a bunch of
60-110msec samples might be enough to cause his hits to go awry.

We were about to get to the question I dread: "How can I fix this?" This is
the  leap-of-faith moment, where we end up saying in essence:

Your vendor(s) lied to you. You can fix this yourself. Just buy a spare
> router and install some Open Source software...
>

I always fear this moment because there's such a high likelihood of getting
egg on the face from one or many of the reasons listed in the original
post. If they happen, I usually slink away, and say to check the "What Can
I Do About Bufferbloat" page.

Fortunately, he had a Ubiquiti UDM Pro, so he said, "Hey, I turned on smart
queues and it looks way better." With that sticky point out of the way,
there were several more interchanges where I got to say that both the
router and the Wi-Fi can create bufferbloat and that these bufferbloat
measurement tools are only broad indicators of "network goodness".

So this is one circumstance where it worked out. But I ache to have some
advice to address the dread-causing question. Any thoughts? Thanks.

[-- Attachment #2: Type: text/html, Size: 2655 bytes --]