To Adopt or Not to Adopt L4S-Compatible Congestion Control? Understanding Performance in a Partial L4S Deployment

TL;DR

This study questions whether L4S-compatible congestion control is worth adopting in partial deployments by examining sender perspectives under uncertain bottleneck conditions. Using FABRIC experiments, it compares TCP Prague and L4S-enabled BBRv2 (both with AccECN) against non-L4S flows across diverse queueing environments, including FQ, CoDel, PIE, and DualPI2. The results show that an L4S sender can be harmful to or harmed by non-L4S flows in many settings, with ultra-low latency benefits typically realized only when explicit flow isolation is in place; BBRv2 often fares better than Prague, while BBRv3 offers limited, inconsistent advantages. The findings suggest cautious consideration for adoption, highlighting the need for isolation-focused AQMs and broader testing across network configurations before widespread deployment.

Abstract

With few exceptions, the path to deployment for any Internet technology requires that there be some benefit to unilateral adoption of the new technology. In an Internet where the technology is not fully deployed, is an individual better off sticking to the status quo, or adopting the new technology? This question is especially relevant in the context of the Low Latency, Low Loss, Scalable Throughput (L4S) architecture, where the full benefit is realized only when compatible protocols (scalable congestion control, accurate ECN, and flow isolation at queues) are adopted at both endpoints of a connection and also at the bottleneck router. In this paper, we consider the perspective of the sender of an L4S flow using scalable congestion control, without knowing whether the bottleneck router uses an L4S queue, or whether other flows sharing the bottleneck queue are also using scalable congestion control. We show that whether the sender uses TCP Prague or BBRv2 as the scalable congestion control, it cannot be assured that it will not harm or be harmed by another flow sharing the bottleneck link. We further show that the harm is not necessarily mitigated when a scalable flow shares a bottleneck with multiple classic flows. Finally, we evaluate the approach of BBRv3, where scalable congestion control is used only when the path delay is small, with ECN feedback ignored otherwise, and show that it does not solve the coexistence problem.

Figures (9)

• Figure 1: Adapted from prague-paper and to-switch-or-not-to-switch-prague, we conduct a FABRIC experiment to illustrate the fundamental limitation of classic congestion control, using a line network with 100 Mbps bottleneck capacity, a base RTT of 25 ms, and a 2 BDP FIFO bottleneck with ECN. Artifacts to reproduce this are available at github.
• Figure 2: Experiment Topology
• Figure 3: Throughput of Prague (and CUBIC, in parentheses) in Mbps when sharing a bottleneck (Single Queue AQMs).
• Figure 7: Throughput of Prague (and BBRv2, in parentheses) in Mbps when sharing a bottleneck (single queue AQMs). (classic ECN marking on BBRv2 receiver)
• Figure 11: Throughput of Prague (and BBRv2, in parentheses) in Mbps when sharing a bottleneck. (DCTCP-style ECN marking on BBRv2 receiver)