CCID5: Evaluating BBR for Datagram Congestion Control Protocol

By on 3 Nov 2021

Category: Tech matters

Tags: , ,

1 Comment

Blog home

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.

General architecture of MP-DCCP framework
Figure 1 — General architecture of MP-DCCP framework. Here, the traffic generated at the sender side is encapsulated and allocated to any of the available DCCP tunnels by the scheduling function. At the receiver side, the reordering function will correct possible packet scrambling, and the traffic will be finally decapsulated and delivered. An open-source implementation of this framework for the Linux kernel version 4.14.111 is available for download. The implementation of CCID5 was carried out within the same deployment.

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.

Graphs showing comparison of BBR and CCID5 latency and throughput response over a single path.
Figure 2 — Comparison of BBR and CCID5 response over a single path.

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.

Graphs showing latency performance of UDP carried over MP-DCCP framework with CCID2 and CCID5.
Figure 3 — UDP carried over MP-DCCP framework with CCID2 and CCID5.

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

Graphs showing latency and throughput for TCP carried over MP-DCCP framework with CCID2 and CCID5.
Figure 4 — TCP carried over MP-DCCP framework with CCID2 and CCID5.

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.

Rate this article

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.

One Comment

Leave a Reply

Your email address will not be published.

Top