This sounds amazing. Poor TCP congestion control algorithms have long been the limiting factor of today's broadband connections never reaching their potential speed. It looks like this was already patched into the kernel for those interested: https://lwn.net/Articles/701149/ - can't wait to experiment with this!
This is a delay-based scheme; it is unlikely to work well if competing with a drop-based aggressive scheme like TCP Cubic.
As a result, while BBR is fantastic for deployment e.g. in Google's private WAN, it's unclear how well it would do in the Internet, and initial experiments are not promising [1].
I think that's a risk for sure -- if it can't compete with Cubic, what will the user experience be like? The authors note that it's still actively being researched. They do cite encouraging public internet deployment test results though:
"BBR is being deployed on Google.com and YouTube video servers. Google is running small-scale experiments in which a small percentage of users are randomly assigned either BBR or CUBIC. Playbacks using BBR show significant improvement in all of YouTube's quality-of-experience metrics, possibly because BBR's behavior is more consistent and predictable. BBR only slightly improves connection throughput because YouTube already adapts the server's streaming rate to well below BtlBw to minimize bufferbloat and rebuffer events. Even so, BBR reduces median RTT by 53 percent on average globally and by more than 80 percent in the developing world."
Regarding deployment: between Apple and Samsung they control 75% of mobile all mobile Internet traffic [1]. So with only two vendors deploying, we could see a very fast pace of adoption. Given there are now more mobile users than desktop users [2] and that mobile media time is now exceeding desktop media streaming time [2] it seems like mobile Internet traffic could be the majority (would love to know if anyone can find better stats on this, i.e. % of Internet traffic mobile vs desktop). A decade ago
But yes on private-backbone use cases like Google (and other companies with a lot of private fiber networks) are likely the most immediate adopters it could easily save millions a year -- 133x throughput (!)
"Manually raising the receive buffer on one US-Europe path caused BBR immediately to reach 2 Gbps, while CUBIC remained at 15 Mbps—the 133x relative improvement predicted by Mathis et al."
[+] [-] r1ch|9 years ago|reply
[+] [-] akshayn|9 years ago|reply
As a result, while BBR is fantastic for deployment e.g. in Google's private WAN, it's unclear how well it would do in the Internet, and initial experiments are not promising [1].
[1] http://www.ietf.org/mail-archive/web/tsvwg/current/msg14798....
[+] [-] tedd4u|9 years ago|reply
"BBR is being deployed on Google.com and YouTube video servers. Google is running small-scale experiments in which a small percentage of users are randomly assigned either BBR or CUBIC. Playbacks using BBR show significant improvement in all of YouTube's quality-of-experience metrics, possibly because BBR's behavior is more consistent and predictable. BBR only slightly improves connection throughput because YouTube already adapts the server's streaming rate to well below BtlBw to minimize bufferbloat and rebuffer events. Even so, BBR reduces median RTT by 53 percent on average globally and by more than 80 percent in the developing world."
Regarding deployment: between Apple and Samsung they control 75% of mobile all mobile Internet traffic [1]. So with only two vendors deploying, we could see a very fast pace of adoption. Given there are now more mobile users than desktop users [2] and that mobile media time is now exceeding desktop media streaming time [2] it seems like mobile Internet traffic could be the majority (would love to know if anyone can find better stats on this, i.e. % of Internet traffic mobile vs desktop). A decade ago
But yes on private-backbone use cases like Google (and other companies with a lot of private fiber networks) are likely the most immediate adopters it could easily save millions a year -- 133x throughput (!)
"Manually raising the receive buffer on one US-Europe path caused BBR immediately to reach 2 Gbps, while CUBIC remained at 15 Mbps—the 133x relative improvement predicted by Mathis et al."
[1] http://marketingland.com/report-apple-iphone-drives-half-mob... [2] https://hostingfacts.com/internet-facts-stats-2016/
[+] [-] X86BSD|9 years ago|reply