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

[Stephen Hemminger <stephen@networkplumber.org>]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

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

> Sebastian Moeller <moeller0@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@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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]