Re:BBR, the new kid on the TCP block
by baq on Tuesday May 09, 2017 @06:08AM
(#14298812)
There's a 'Sharing' section near the end where two scenarios are compared. Doesn't look like an exhaustive test, rather the opposite.
[ Parent
| on HN ]
Re:BBR, the new kid on the TCP block
by morecoffee on Tuesday May 09, 2017 @12:22PM
(#14301328)
What about BBR sharing with BBR? Really, what is the reason this shouldn't be rolled out as the default everywhere?
Re:BBR, the new kid on the TCP block
by huhtenberg on Tuesday May 09, 2017 @06:25AM
(#14298858)
Sure, I read the article. That section covers just CUBIC.
It also doesn't discuss competition between BBR users. Playing nicely with your neighbors is important for the health of the Internet.
Several BBR flows do actually converge quite nicely to a fair share of bandwidth. Take a look at the presentation the guys from google gave at the IETF 97 in Seoul: https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-b...
I think there is also a recording of that session somewhere on youtube.
Also, the complete paper can be downloaded for free at http://queue.acm.org/detail.cfm?id=3022184
It doesn't discuss competition with either many users, with things like webrtc, or with those evil dial-a-speed schemes.
The internet is complex.
However, since the dial-a-speed evildoers haven't caused much controversy in the grand scheme of things, I don't think BPR will do real harm in that case.
I'm more concerned about unloaded parts of a circuit. Suppose some BPR streams fill one hop, and share other, higher-capacity, hops with Reno. Does Reno do as well then as it would if the BPR streams were Reno?