[Cerowrt-devel] Invisibility of bufferbloat and its remedies
Dave Taht
dave.taht at gmail.com
Mon Jun 18 17:14:21 EDT 2018
>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
More information about the Cerowrt-devel
mailing list