>> 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
Description: OpenPGP digital signature
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat