|
|
|
|
|
by tedd4u
3492 days ago
|
|
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." [1] http://marketingland.com/report-apple-iphone-drives-half-mob...
[2] https://hostingfacts.com/internet-facts-stats-2016/ |
|
This isn't to say that BBR is "bad" - just that it's not mentioned what the "quality of experience metrics" are. They're obviously not getting better throughput, and the only way they can improve delay is if the edge buffer is overprovisioned (i.e. bufferbloat). In that case (edge bottleneck, relatively low BW), I'd be interested to see a comparison to Sprout[1].
[1] https://www.usenix.org/system/files/conference/nsdi13/nsdi13...