From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A1D393B2A4; Mon, 18 Jun 2018 17:02:26 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id ADC0920090; Mon, 18 Jun 2018 17:16:33 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 05BE11815; Mon, 18 Jun 2018 16:59:26 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0219C1814; Mon, 18 Jun 2018 16:59:26 -0400 (EDT) From: Michael Richardson To: "dpreed\@deepplum.com" cc: "Dave Taht" , cerowrt-devel@lists.bufferbloat.net, bloat In-Reply-To: <1529339194.276412941@apps.rackspace.com> References: <1529339194.276412941@apps.rackspace.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Subject: Re: [Bloat] [Cerowrt-devel] Invisibility of bufferbloat and its remedies X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 21:02:26 -0000 --=-=-= Content-Type: text/plain dpreed@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@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWygdK4CLcPvd0N1lAQIVAwgAhE8RgAwCejLd41WNLLYjNsuiEo5vLZPW azYvKCaR1j1Yknj79Ll7GEAMp+U3FWCLasxphstYBbs9ggvM/7j8GsciE+RnuoBQ UqrlwoBRdMalsOlcvgt4e5Qv4jm8j61OJnhU8mYNN0ck/CB9b6p2lIDTERazgjog vuvp8k/lt6pGVfH/nEZQy2if990xqjir70fPa6fGcAaMSV3t/P23cwEdp3D/pPx8 SclGSPy1oXX/pVrvJw3dfHgZ0Lnc04RZqqEBKshaH6AP6qtmEuDEWp2iGgdgt7Kb w3XNSQ6Q7qWecC2ySn+KLD4pBoQMuC8g1Ka9SSofMLSi9e2NtD0BaQ== =/pcr -----END PGP SIGNATURE----- --=-=-=--