Bottleneck Bandwidth and Round-trip time (BBR) is a relatively new congestion control algorithm for TCP traffic that has been proven to overcome problems like low throughput, long delays, and buffer-bloating typically present in loss-based Congestion Control (CC) algorithms.
In this post, I will describe the performance of BBRv1 for a Datagram Congestion Control Protocol (DCCP) implementation that we at Deutsche Telekom carried out and established in testbeds with Karlstad University and the City University of London over single and multi-path scenarios. In DCCP (RFC 4340), the CC algorithms have a unique identifier called CCID; our BBR implementation has the identifier CCID5.
The motivation behind this research stems from recent extensions of DCCP to support sessions working across multiple paths simultaneously. These extensions (MP-DCCP) are meant to enable multi-path transport for latency-sensitive services and/or services with no or less demand on reliable delivery.
MP-DCCP (recently IETG WG adopted) has also been used in combination with virtual network interfaces, scheduling and reordering functions as part of a framework (Figure 1) that is capable of transporting any IP traffic across multiple access networks, and, therefore, suitable to be used for Hybrid Access scenarios or mobile multi-connectivity in compliance with the ATSSS specification at 3GPP Rel-16.
Our implementation of BBR for DCCP sought to verify if the conceptual basis of BBR works for DCCP and to enhance this MP-DCCP framework.
CCID5 vs CCID2
We compared the performance of CCID5 with CCID2 (the default CC algorithm for DCCP) over single and multi-path scenarios. The experiments were mainly focused on observing the response of both CC algorithms in terms of latency and received throughput when the available bandwidth is limited.
In the single path case, the TCP response for BBR and CUBIC was used as a baseline reference. Under this scenario, the results (Figure 2) show that after a bandwidth limitation is imposed in the path (t>5s), BBR and CCID5 avoid buffer bloat, keeping the values of the latencies low. Whereas, CUBIC and CCID2 fill up the buffer, causing higher latencies.
The results corresponding to the test cases over the multi-path scenarios, carrying UDP and TCP traffic, are represented in Figures 3 and 4 respectively.
During the first five seconds of the UDP traffic test, both CC algorithms have approximately the same response and only one of the paths is used due to the prioritization given by the Cheapest Pipe First (CPF) scheduler. However, once the available bandwidth is limited, CCID2 takes some seconds to detect congestion, filling up the buffer and thus causing higher latencies and delaying the CPF scheduler to start transmitting over the secondary path. On the other hand, CCID5 detects the congestion faster, allowing the scheduler to react earlier, avoiding filling up the buffer and achieving lower latencies in comparison to CCID2.
Similarly, CCID5 provides lower latencies than CCID2 in the TCP traffic test too, which seems to be a good indicator when MP-DCCP is used to carry QUIC — similar characteristics like TCP — traffic in ATSSS or Hybrid Access scenarios (Figure 4).
BBRv1 ✅ BBRv2❓
With our first implementation of BBRv1 for DCCP, we’ve shown its benefit in terms of latency reduction and proven its impact in the multi-path scenarios where it reduces the reordering effort and provides the stability to carry TCP streams on top of CCID5 controlled DCCP tunnels.
In future work, we plan to extend our measurement framework to add more constraints and metrics as well as implement BBRv2 for DCCP performing its corresponding evaluation.
Please refer to our paper and presentation at ANRW 2021 for more details on our methodology.
Nathalie Romo Moreno works as Network Architect at the Strategy and Technology Innovation department of Deutsche Telekom, where her work has been focused on research and development within the multiconnectivity and FMC areas.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Good stuff!