# Performance Evaluation of TCP BBRv3 in Networks with Multiple Round Trip Times
###### Abstract  
The Transmission Control Protocol (TCP) serves as a cornerstone mechanism for implementing Congestion Control (CC) across the Internet. Designing a solution that provides high bandwidth utilization and mitigates the phenomenon of bufferbloat across a spectrum of diverse scenarios poses a considerable challenge. The introduction of Bottleneck Bandwidth and Round Trip propagation time (BBR) in 2016 marked a significant shift in congestion control methodology. Its improved performance and adaptability contributed to the initial acclaim and widespread interest that it received.. Unlike most currently used CCs, it operates around Kleinrock's optimal point, thus offering high throughput even in lossy networks while preventing buffer saturation. Unfortunately, it quickly became evident that BBR was unable to fairly share bandwidth with flows characterized by different path delays, as well as loss-based CCs. In response, Google recently introduced a third iteration to address these shortcomings. This study explores the performance of BBRv3 across a wide range of scenarios, thereby considering different buffer sizes and paths with varying Round Trip Times (RTTs), and it evaluates its superiority over its predecessors. Through extensive simulations, this work assesses whether BBRv3 can finally play fair with other bandwidth contenders, which is a critical consideration given the widespread deployment of BBR. The framework is publicly available to facilitate additional validation and ensure the reproducibility of the study's findings. The results indicate that while BBRv3 demonstrates enhanced fairness towards loss-based CC algorithms, it struggles when competing against other BBR flows, especially in multi-RTT networks, thus falling short even when compared to the initial version. TCP; BBRv3; BBRv2; BBRv1; CUBIC; congestion control; performance evaluation; simulation; fairness +
Footnote †: journal:  
BDP, the connection will not be able to fully utilize the link. Conversely, surpassing the (A) point leads to queue formation and subsequent performance degradation. At the same time, [PERSON] presented a paper that proved it was impossible to design a distributed algorithm that would converge at Kleinrock's optimal point [2]. These results motivated research in other directions for congestion control design. Most common congestion control mechanisms follow the loss-based approach, which moves the operational point to the right towards point (B). This leads to several undesired issues such as buffer overflow and bufferbloat, i.e., \"persistently full buffer\", as described in [3]. A full buffer cannot compensate for packet bursts, which inherently occur due to the best-effort nature of the network. This results in substantial delays, thus impeding the real-time interactions necessary for numerous applications and consequently leading to poor user experiences. Moreover, it hinders latency-sensitive applications such as web services and financial transactions, as well as the low-latency communication required in Internet of Things (IoT) networks. Full buffers additionally degrade transmission performance in mobile and wireless networks, which are already subject to highly variable latency. Most commonly used TCP variants, e.g., CUBIC, follow the loss-based approach. CUBIC demonstrates high performance across various scenarios, particularly when coupled with Active Queue Management (AQM), thus resulting in efficient bandwidth utilization, fair bandwidth sharing, and a relatively low drop ratio [4; 5]. However, its effectiveness is limited as link capacities scale up to 10 or 100 Gbps, especially when coupled with long RTTs. For instance, to fully utilize a 10 Gbps link with a 100 ms RTT, CUBIC requires a packet loss ratio below 0.000003% and intervals exceeding 40 s between any instances of packet loss--criteria that are impractical given typical link characteristics. In the case of a 1% packet loss, a common occurrence in links exceeding 100 ms, CUBIC fails to achieve a throughput exceeding 3 Mbps [6].