Re: [Bloat] geoff huston's take on BBR

[Matthias Tafelmeier <matthias.tafelmeier@gmx.net>]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1840 bytes --]


>> Interesting. Potentially, all affectuated. After having applied the BBR
>> 2.0, we might are back to Cubic? :D
> I don't understand what you're saying. I think Geoff tested BBR v1.0.
> Explanations for the experienced behavior can be found in our paper
> http://doc.tm.kit.edu/2017-kit-icnp-bbr-authors-copy.pdf, esp. section
> 3. Geoff's findings in the wild nicely confirm our results that were
> performed in more controlled lab settings. Important is though, that
> you always test with multiple concurrent BBR flows...
To put this straight - I meant that all the efferescing outlines as to
BBR were potentially overly hasty, perceive it as a mere utterance. For
BBR2.0 I referred to the slide by Geoff listing the cued improvements
from 1.0 -> 2.0 - insinuating thereby ruling out thinkable 'vantage
aspects' of BBR (excuse my cynicism - early morning ranting!). Good.
Thanks for sharing your work.
>> Moreover, if it tends to be unstable on larger scale - what is Google
>> doing then? Thought they've got a more or less homogeneous BBR driven
>> TCP flow ecosystem - at least internally!? Was all propaganda? When
>> speculating, might working for them since of centrally handled flow
>> steering approaches - "imposing inter-flow fairness".
> There are certain situations where BBR might work well:
> 1) you only have a single flow at the bottleneck, might be the case in
> their B4 scenario
> 2) The senders a application limited (e.g., YouTube)
> 3) The bottleneck buffer is much larger than a BDP
>    (then BDP will limit the queue size between 1 and 1.5 BDP)
> However, BBR has no explicit fairness mechanism, so sometimes
> one will see quite unfair shares for longer periods,
> even if there are only BBR flows present at then bottleneck.

ACK

-- 
Besten Gruß

Matthias Tafelmeier


[-- Attachment #1.1.1.2: Type: text/html, Size: 2741 bytes --]

[-- Attachment #1.1.2: 0xE0164F5B8ADF343B.asc --]
[-- Type: application/pgp-keys, Size: 5250 bytes --]

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