[Bloat] [Cerowrt-devel] Invisibility of bufferbloat and its remedies

[Dave Taht]

>From a ton of memes at: https://me.me/t/buffering

"Dear youtube:

I can deal with ads
I can deal with buffer
But when ads buffer, I suffer"

and innumerable others, some NSFW

https://me.me/i/16133421

On Mon, Jun 18, 2018 at 1:59 PM, Michael Richardson <mcr at sandelman.ca> wrote:
>
> dpreed at deepplum.com <dpreed at deepplum.com> wrote:
>     > I blame IETF members, individually and collectively. If ietf exists for
>     > any reason other than as a boondoggle for world travel, it's for
>     > resolving issues like this one.
>
> Slightly fair.
>
> A thing that I tried to get ISOC's "deploy360" to do was to create a wall of
> shame on bufferbloat five or eight years ago.  It was before the AQM WG did
> any work, I think.  I wanted ISOC to collect the data, because I wanted it
> visible at the CTO level.
>
> At the very very least, I wanted a series of curated links to statements from
> various equipment vendors about the problem.
> I.e. www.example.com/bufferbloat.html for example in
> {cisco,juniper,huawei,calix,...}
>
> I asked many of my IETF contacts at these places if they knew who at their
> company was dealing with it.  I also asked salespeople that I dealt with,
> hoping to put pressure the other way.  I got nowhere.
>
> I wanted, at the very least, to get them to acknowledge that there was a
> problem, even if they didn't have an estimate on a solution, at least I could
> point the salesperson at the page on their site, and say, "I'll buy when you
> get me a delivery date".
> A major client of mine lost three large (VoIP) customers because of hidden
> bufferbloat in Bell Canada's LAN extension service... which "never lost any
> packets", the sales people explained.  It was at a time when we
> weren't quite using the term bufferbloat, and we didn't quite know how to
> measure it in convincing ways.
>
> I still think that this is a good idea.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619