{ "id": "ep7j2gxzwa", "slug": "bbr-congestion-control", "title": "BBR (congestion control)", "updated": "2026-10-15", "topic_path": [ { "id": "technology", "label": "Technology and the built world", "api_url": "https://www.edgepedia.org/api/v1/topics/technology" }, { "id": "technology.computing", "label": "Computing and digital systems", "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing" }, { "id": "technology.computing.networks", "label": "Networks and security", "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing.networks" }, { "id": "technology.computing.networks.networking-fundamentals", "label": "Networking fundamentals and architecture", "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing.networks.networking-fundamentals" }, { "id": "technology.computing.networks.internet-protocol-suite", "label": "Internet protocol suite", "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing.networks.internet-protocol-suite" } ], "geo": [ { "id": "geo.us.t2001.technology.computing.networks.networking-fundamentals", "label": "United States · 2001 to 2020: Networking fundamentals and architecture", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.us.t2001.technology.computing.networks.networking-fundamentals", "path": [ { "id": "geo.us", "label": "United States", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.us" }, { "id": "geo.us.t2001", "label": "United States · 2001 to 2020", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.us.t2001" }, { "id": "geo.us.t2001.technology", "label": "Technology and the built world", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.us.t2001.technology" }, { "id": "geo.us.t2001.technology.computing", "label": "Computing and digital systems", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.us.t2001.technology.computing" }, { "id": "geo.us.t2001.technology.computing.networks", "label": "Networks and security", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.us.t2001.technology.computing.networks" }, { "id": "geo.us.t2001.technology.computing.networks.networking-fundamentals", "label": "Networking fundamentals and architecture", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.us.t2001.technology.computing.networks.networking-fundamentals" } ] } ], "excerpt": "BBR (Bottleneck Bandwidth and Round-trip propagation time) is a TCP and QUIC congestion control algorithm developed by Google in 2016 that models the network path instead of using packet loss as its congestion signal.", "snippet": "BBR (Bottleneck Bandwidth and Round-trip propagation time) is a TCP and QUIC congestion control algorithm developed by Google in 2016 that models the network path instead of using packet loss as its congestion signal.", "node": "technology.computing.networks.internet-protocol-suite", "markdown": "# BBR (congestion control)\n\nBBR (Bottleneck Bandwidth and Round-trip propagation time) is a TCP and QUIC congestion control algorithm developed by Google in 2016 that builds an explicit model of the network path from measured delivery rate and round-trip time, instead of treating packet loss as the primary signal of congestion.[1](https://doi.org/10.1145/3793537) It was described in a 2016 ACM Queue paper by Neal Cardwell, Yuchung Cheng, C. Stephen Gunn, Soheil Hassas Yeganeh, and Van Jacobson of Google.[2](https://research.google/pubs/bbr-congestion-based-congestion-control-2/)\n\n| Key fact | Detail |\n|---|---|\n| Origin | Developed by Google in 2016 as a model-based alternative to loss-based congestion control such as Reno and CUBIC[1](https://doi.org/10.1145/3793537) |\n| Path model | Estimates the bottleneck bandwidth (BtlBw) and minimum round-trip propagation time (RTprop), then regulates the sending rate and in-flight data around the estimated BDP[1](https://doi.org/10.1145/3793537) |\n| Versions | BBRv1 (2016), BBRv2 (2018, adds ECN and loss-rate signals), BBRv3 (August 2023, BBRv2 plus bug fixes and tuning)[1](https://doi.org/10.1145/3793537) |\n| Signals in BBRv3 | Throughput, RTT, an explicit loss rate cap of 2%, and shallow-threshold ECN similar to DCTCP/L4S[3](https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00) |\n| Deployment | TCP congestion control for all Google internal WAN traffic and for google.com and YouTube public Internet TCP traffic; QUIC use in A/B experiments[3](https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00) |\n| Implementations | Open source for TCP and QUIC; Linux TCP BBRv3 released under a dual GPLv2/BSD license[4](https://datatracker.ietf.org/doc/draft-ietf-ccwg-bbr/) • [3](https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00) |\n| Standardization | Specified in the IETF Congestion Control Working Group Internet-Draft draft-ietf-ccwg-bbr, targeting publication as an Experimental RFC[4](https://datatracker.ietf.org/doc/draft-ietf-ccwg-bbr/) |\n\n## Why a model-based algorithm\n\n[TCP congestion control](https://www.edgepedia.org/tcp-congestion-control) was created in the 1980s on the assumption that packet loss indicates congestion. That equivalence held under the technology of the time, but as [network interface controllers](https://www.edgepedia.org/network-interface-controller) moved from Mbps to Gbps and memory from KB to GB, the relationship between loss and congestion became weaker.[2](https://research.google/pubs/bbr-congestion-based-congestion-control-2/) Loss-based algorithms such as CUBIC, the default TCP congestion control in the Linux, Windows, and Apple stacks,[5](https://datatracker.ietf.org/doc/html/rfc9438) react to the two extremes badly: when bottleneck buffers are large they keep them full, causing bufferbloat, the excessive delay from too many buffered packets; when buffers are small they misinterpret loss as congestion and drive throughput down.[2](https://research.google/pubs/bbr-congestion-based-congestion-control-2/)\n\nBBR instead estimates two quantities for the path: the bottleneck bandwidth (BtlBw) and the minimum round-trip propagation time (RTprop). Their product, the bandwidth-delay product, is the amount of in-flight data that exactly fills the pipe without queuing. BBR regulates its sending rate and in-flight volume around this estimate, probing continuously to track changes, with the aim of full bandwidth utilization without filling bottleneck buffers.[1](https://doi.org/10.1145/3793537) Relative to loss-based algorithms, the IETF specification states that BBR offers substantially higher throughput on bottlenecks with shallow buffers or random losses, and substantially lower queueing delays on bottlenecks with deep buffers.[4](https://datatracker.ietf.org/doc/draft-ietf-ccwg-bbr/)\n\n## Versions\n\n**BBRv1.** The first release used bandwidth and RTT as its primary signals, with loss used only over short time scales.[3](https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00) Google's initial results showed significantly improved bandwidth utilization and median round-trip time in its use cases, but researchers identified several problems. Flows with longer round-trip times consume more bandwidth than short-RTT flows sharing the same bottleneck, because BBRv1 computes a larger bandwidth-delay product for them and injects more data.[1](https://doi.org/10.1145/3793537) A deployment study on geo-distributed cloud servers found that with an RTT ratio of 10 between competing flows, even flow starvation could occur, since the amount of data sent while probing scales with RTT.[6](https://arxiv.org/abs/1706.09115) When multiple BBRv1 flows coexist, each overestimates its delivery rate, producing standing queues beyond 1.5 times the BDP, packet loss, and unfair sharing when buffers are small.[1](https://doi.org/10.1145/3793537) BBRv1 also coexists poorly with loss-based algorithms, showing aggressive probing and unfair bandwidth grabs.[1](https://doi.org/10.1145/3793537) An independent evaluation at the [Karlsruhe Institute of Technology](https://www.edgepedia.org/karlsruhe-institute-of-technology) using the Linux 4.9 implementation at 1 and 10 Gbit/s confirmed the intended behavior in some settings but also found increased queuing delays, unfairness, and massive packet loss.[7](https://publikationen.bibliothek.kit.edu/1000085694)\n\n**BBRv2.** Google proposed BBRv2 in 2018 to address these limitations, adding [explicit congestion notification](https://www.edgepedia.org/explicit-congestion-notification) (ECN) and the packet loss rate as model parameters alongside BtlBw and RTprop.[1](https://doi.org/10.1145/3793537) Google reported better fairness against loss-based control and fewer retransmissions with small buffers, and studies found that ECN support improved bandwidth distribution and reduced standing queues.[1](https://doi.org/10.1145/3793537) A measurement study on the Dropbox edge network, which had run BBRv1 in production since 2017, concluded that BBRv2, with its explicit loss targets, in-flight limits, differential probing, and headroom for new flows, was a definite improvement over both BBRv1 and CUBIC.[8](https://arxiv.org/abs/2008.07699) Independent analysis nevertheless found costs: slow responsiveness to bandwidth changes and low resilience to random losses,[9](https://www.sciencedirect.com/science/article/pii/S1389128622000226) and researchers reported remaining issues with mixed-RTT flow coexistence and competition with other algorithms.[1](https://doi.org/10.1145/3793537)\n\n**BBRv3.** Released in August 2023, BBRv3 is BBRv2 plus bug fixes and performance tuning.[1](https://doi.org/10.1145/3793537) Its input signals are throughput, RTT, loss with an explicit loss rate cap of 2%, and shallow-threshold ECN similar to DCTCP and L4S; it starts in slow-start until throughput plateaus or the ECN or loss rate exceeds target.[3](https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00) Google reports that compared with BBRv1 it has better coexistence with Reno and CUBIC, lower loss rates, lower latency for short web requests, and throughput within 1% of v1 on YouTube.[3](https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00) A variant, BBR.Swift, uses network RTT excluding receiver delay as the primary signal and serves as TCP congestion control inside Google datacenters.[3](https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00)\n\n## Fairness\n\nFairness remains the central open engineering problem across BBR versions. Two notions are distinguished: intra-protocol fairness, meaning even sharing among BBR flows themselves, and inter-protocol fairness, meaning equitable sharing with flows run by other algorithms such as CUBIC on the same bottleneck.[1](https://doi.org/10.1145/3793537) BBRv1's RTT unfairness, in which long-RTT flows dominate short ones, was severe enough that malicious users could obtain a larger bandwidth share simply by increasing delay.[10](https://www.sciencedirect.com/science/article/pii/S0140366422004650) Later versions reduce but do not eliminate these problems: a 2024 NS-3 evaluation found unfairness in competing BBR and BBR-versus-CUBIC scenarios,[11](https://arxiv.org/abs/2410.22560) and control-theoretic analysis shows that BBR/CUBIC competition often suffers from sending-rate oscillation that harms BBR's fairness.[12](https://arxiv.org/abs/2510.22773) A large body of derivative algorithms, including BBRv2+, BBR-A, and BBR-EFRA, targets these fairness and retransmission issues specifically.[9](https://www.sciencedirect.com/science/article/pii/S1389128622000226)\n\n## Deployment and standardization\n\nAt Google, BBRv3 is the TCP congestion control for all internal WAN traffic and for all google.com and YouTube public Internet TCP traffic, with A/B experiments running BBRv3 against v1 for a small percentage of QUIC users on google.com and YouTube.[3](https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00) Linux TCP BBRv3 is open source under a dual GPLv2/BSD license, and Google has planned to upgrade the BBRv1 code in the Linux TCP \"bbr\" module to BBRv3 in place and to submit it for mainline inclusion.[3](https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00) QUIC BBR code is maintained in Google's quiche repository.[13](https://github.com/google/bbr/blob/master/README.md)\n\nWithin the IETF, BBR is a Congestion Control Working Group working group item, specified in draft-ietf-ccwg-bbr, which documents version 3 of the algorithm and is targeted for publication as an Experimental RFC.[4](https://datatracker.ietf.org/doc/draft-ietf-ccwg-bbr/) Because BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment, open source implementations exist for both TCP and QUIC.[4](https://datatracker.ietf.org/doc/draft-ietf-ccwg-bbr/)\n\n## Ongoing evaluation\n\nResearch on BBRv3 in next-generation network contexts continues. A 2025 ACM Computing Surveys survey of BBRv1 through BBRv3 experimentally evaluated BBRv3 against 5G-Advanced use cases, finding that balancing fairness and optimizing buffering for diverse quality-of-service requirements remains challenging, and reviews AI-based enhancements to BBR as a future direction.[1](https://doi.org/10.1145/3793537) Independent testbed work quantifying BBRv3's fairness and convergence against CUBIC using Jain's Fairness Index and the coefficient of variation has reported convergence issues within BBRv3 flows themselves.[14](https://jcbi.org/index.php/Main/article/view/1079)\n\n## References\n\n1. [BBR Congestion Control Algorithms: Evolution, Challenges and Future Directions, ACM Computing Surveys 58(9), Article 235](https://doi.org/10.1145/3793537)\n2. [Cardwell, Cheng, Gunn, Hassas Yeganeh, Jacobson. BBR: Congestion-Based Congestion Control. ACM Queue 14, September-October 2016](https://research.google/pubs/bbr-congestion-based-congestion-control-2/)\n3. [BBRv3: Algorithm Overview and Google's Public Internet Deployment, IETF 119 CCWG slides, March 2024](https://datatracker.ietf.org/meeting/119/materials/slides-119-ccwg-bbrv3-overview-and-google-deployment-00)\n4. [draft-ietf-ccwg-bbr-06, BBR Congestion Control, IETF Congestion Control Working Group](https://datatracker.ietf.org/doc/draft-ietf-ccwg-bbr/)\n5. [RFC 9438, CUBIC for Fast and Long-Distance Networks, August 2023](https://datatracker.ietf.org/doc/html/rfc9438)\n6. [Ma, Jiang, Wang, Li. Fairness of Congestion-Based Congestion Control: Experimental Evaluation and Analysis, arXiv:1706.09115](https://arxiv.org/abs/1706.09115)\n7. [Hock, Bless, Zitterbart. Experimental Evaluation of BBR Congestion Control, IEEE ICNP 2017, KIT](https://publikationen.bibliothek.kit.edu/1000085694)\n8. [Ivanov. Evaluating BBRv2 on the Dropbox Edge Network, arXiv:2008.07699](https://arxiv.org/abs/2008.07699)\n9. [Yang et al. BBRv2+: Towards balancing aggressiveness and fairness with delay-based bandwidth probing, Computer Networks, 2022](https://www.sciencedirect.com/science/article/pii/S1389128622000226)\n10. [BBR With Enhanced Fairness (BBR-EFRA): A new enhanced RTT fairness for BBR congestion control algorithm, Computer Communications, 2022](https://www.sciencedirect.com/science/article/pii/S0140366422004650)\n11. [BBR Fairness Evaluation Using NS-3, arXiv:2410.22560](https://arxiv.org/abs/2410.22560)\n12. [A Control-Theoretic Perspective on BBR/CUBIC Congestion-Control Competition, arXiv:2510.22773](https://arxiv.org/abs/2510.22773)\n13. [google/bbr repository README](https://github.com/google/bbr/blob/master/README.md)\n14. [BBR v3-Cubic smackdown: A Fairness and Convergence Quantitative Evaluation, Journal of Computing & Biomedical Informatics](https://jcbi.org/index.php/Main/article/view/1079)\n\n---\n*Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Networks and security › Networking fundamentals and architecture › Internet protocol suite*\n\n*Initially written Oct 15, 2026*\n\n*Copyright 2026 EdgeChat AI, a subsidiary of Biostate AI.*\n\nLicense: Edgepedia Community License 1.0, https://www.edgepedia.org/edgepedia/license\n", "same_as": [], "url": "https://www.edgepedia.org/bbr-congestion-control", "markdown_url": "https://www.edgepedia.org/bbr-congestion-control.md", "license": { "name": "Edgepedia Community License 1.0", "url": "https://www.edgepedia.org/edgepedia/license", "summary": "Free with credit, commercial use included. AI training is open to everyone. For other uses, organizations over USD 100M in revenue or 100M monthly users license separately.", "spdx": "LicenseRef-Edgepedia-Community-1.0" }, "credit": "\"BBR (congestion control)\", Edgepedia (EdgeChat), https://www.edgepedia.org/bbr-congestion-control. Edgepedia Community License 1.0.", "credit_md": "\"[BBR (congestion control)](https://www.edgepedia.org/bbr-congestion-control)\", Edgepedia (EdgeChat), [https://www.edgepedia.org/bbr-congestion-control](https://www.edgepedia.org/bbr-congestion-control). [Edgepedia Community License 1.0](https://www.edgepedia.org/edgepedia/license).", "credit_html": "\"BBR (congestion control)\", Edgepedia (EdgeChat), https://www.edgepedia.org/bbr-congestion-control. Edgepedia Community License 1.0.", "speakable": "BBR is a TCP and QUIC congestion control algorithm developed by Google in 2016 that models the network path instead of using packet loss as its congestion signal." }