←back to thread

BBR, the new kid on the TCP block

(blog.apnic.net)
360 points pjf | 3 comments | 09 May 17 08:56 UTC | HN request time: 0.58s | source
Show context
huhtenberg ◴[09 May 17 09:18 UTC] No.14298640[source]▶
Any data on BBR vs Reno and Vegas sharing?

Link capacity estimation is easy. It's the co-existing gracefully with all other flow control options that's tricky.

replies(2): >>14298688 #>>14298812 #
baq ◴[09 May 17 10:08 UTC] No.14298812[source]▶
There's a 'Sharing' section near the end where two scenarios are compared. Doesn't look like an exhaustive test, rather the opposite.
replies(2): >>14298858 #>>14301328 #
huhtenberg ◴[09 May 17 10:25 UTC] No.14298858[source]▶
Sure, I read the article. That section covers just CUBIC.
replies(1): >>14298957 #
1. dsr_ ◴[09 May 17 10:54 UTC] No.14298957[source]▶
It also doesn't discuss competition between BBR users. Playing nicely with your neighbors is important for the health of the Internet.
replies(2): >>14299013 #>>14299099 #
2. Arnt ◴[09 May 17 11:10 UTC] No.14299013[source]▶
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?

3. metafnord ◴[09 May 17 11:34 UTC] No.14299099[source]▶
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