[Make-wifi-fast] [Bloat] the future belongs to pacing

[Stephen Hemminger]

On Sun, 05 Jul 2020 13:43:27 -0400
Michael Richardson <mcr at sandelman.ca> wrote:

> Sebastian Moeller <moeller0 at gmx.de> 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 at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> 

I keep wondering how BBR will respond to intermediaries that aggregate packets.
At higher speeds, won't packet trains happen and would it not get confused
by this? Or is its measurement interval long enough that it doesn't matter.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20200705/ef3ef9f4/attachment.sig>