[Bloat] geoff huston's take on BBR

[Matthias Tafelmeier]

>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20180612/8d77924d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xE0164F5B8ADF343B.asc
Type: application/pgp-keys
Size: 5167 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20180612/8d77924d/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20180612/8d77924d/attachment.sig>