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 5DDEA3CB58; Sun, 5 Jul 2020 13:43:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 385DE389B2; Sun, 5 Jul 2020 13:40:37 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KzV5G1AkQs5T; Sun, 5 Jul 2020 13:40:36 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4D18E389B1; Sun, 5 Jul 2020 13:40:36 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A33D07B; Sun, 5 Jul 2020 13:43:27 -0400 (EDT) From: Michael Richardson To: Sebastian Moeller , Matt Mathis , Carlo Augusto Grazia , Jamshid Mahdavi , bloat , Make-Wifi-fast In-Reply-To: <9A7FBFF1-7F10-41DD-B5C3-5A45254CEB54@gmx.de> References: <5405F10B-F446-4B74-8894-33232145EB2E@gmx.de> <9A7FBFF1-7F10-41DD-B5C3-5A45254CEB54@gmx.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: [Make-wifi-fast] [Bloat] the future belongs to pacing X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2020 17:43:29 -0000 --=-=-= Content-Type: text/plain Sebastian Moeller wrote: > of the sending rate, no? BBRv2 as I understand it will happily run > roughshod over any true rfc3168 AQM on the path, I do not have the > numbers, but I am not fully convinced that typically the most > significant throttling on a CDN to end-user path happens still inside > the CDN's data center... That's an interesting claim. I'm in no position to defend or refute it. If it's true, though, it suggests some interesting solutions, because one can more easily establish trust relationships within the data-center. I'm specifically imagining a clock signal from the Top-of-Rack switch to the senders. Actually, it's not a clock, so much as a automotive style timing shaft running down through all the 1-U servers, with fine vernier adjustments :-) I'm also certain we've seen such technology before. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8CET8ACgkQgItw+93Q 3WXoTwf9H1IxZp/R7c1F51OTVmns7Ev7MZmGBBUZB18KZjzkf2x84UrPDVKXNvbH fwO5eldkYsZXHRoLq8g7ivhYJI7BqG4uHdT2hXBr7h8R89NCU4hyz5XEOWCrpiAR bVOS5L1aqnXlb2ZRc3HXIuAurjYyByLWd7ChsT26jXZL7DYtmMIw2ICC00I/rJOY kkKNEFUOeS+lQ9vKzXCoSkOphjR/PiBQgApB7UEHUD1lK+Se7ag+qJKaf+jflurK DQ6t3U9xkdY6zdnDWNe18YY1LmcORJzCfFtADfTpXpDoJ8HM9DdBVD5iM9U3pkcD Gw/+1vC4deyLNRvnRxPV8wsnMfoOWw== =ugcR -----END PGP SIGNATURE----- --=-=-=--