BBR: Congestion-Based Congestion Control | Hacker News Reader

BBR: Congestion-Based Congestion Control

queue.acm.org

40 pointsalanfranzoni6 comments

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].

[1] http://www.ietf.org/mail-archive/web/tsvwg/current/msg14798....

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/

Right, it's unclear however the context of the YouTube results. If they evaluated on links bottlenecked at the edge at 128Kbps, BBR isn't really competing with Cubic anywhere.

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...

> 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.

It's the servers that matter for this, not the receivers.

I believe I read yesterday this is being committed soon to FreeBSD head.

Reply on news.ycombinator.com