dpr...@deepplum.com <dpr...@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 [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
