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, and ECN feedback is ignored otherwise, and we show that it is not effective for coexistence in this scenario.
What problem does this paper attempt to address?
The main problem that this paper attempts to solve is: in the case of partial deployment of the Low - Latency, Low - Loss, and Scalable Throughput (L4S) architecture, whether the adoption of L4S - compatible congestion control algorithms will have an adverse impact on existing network traffic, or whether it will be adversely affected by other traffic itself. Specifically, the paper explores the following research questions:
1. **Can TCP Prague ensure that it will not harm other traffic sharing the bottleneck link, or that it will not be harmed itself?**
2. **Compared with TCP Prague, does the L4S - compatible BBRv2 have more favorable characteristics to promote its adoption?**
3. **When the bottleneck is shared by a large amount of classical traffic, can the harm caused by or suffered by L4S - compatible traffic be alleviated?**
4. **Is BBRv3 more conducive to the co - existence of L4S - compatible congestion control by automatically turning ECN on and off according to the path - delay threshold?**
### Research Background
The L4S architecture aims to achieve high throughput and ultra - low latency, mainly through the following three mechanisms:
- **Scalable Congestion Control** (such as TCP Prague)
- **Accurate Explicit Congestion Notification (Accurate ECN)**
- **Isolation of L4S and non - L4S flows in the bottleneck queue**
However, in the case of incomplete L4S deployment, these mechanisms may co - exist with other traditional traffic, resulting in performance degradation or other problems. Therefore, the author hopes to evaluate the performance of different congestion control algorithms in the partially - deployed L4S environment through experiments, especially TCP Prague and BBRv2.
### Experimental Design
In order to answer the above research questions, the author designed a series of systematic experiments, using the FABRIC test platform to simulate different network conditions and bottleneck types. The experiments considered multiple queue types, including single - queue and multi - queue, and evaluated the performance of different congestion control algorithms (such as TCP Prague, BBRv2, CUBIC, and BBRv1) under these conditions.
### Results Discussion
#### RQ1: Can TCP Prague ensure that it will not harm other traffic sharing the bottleneck link, or that it will not be harmed itself?
The experimental results show that, whether in a single - queue or multi - queue environment, TCP Prague will indeed have an adverse impact on classical traffic (such as CUBIC and Reno) in some cases, and vice versa. For example, in the absence of AQM or when only using classical ECN, TCP Prague traffic may be suppressed by classical traffic, while when using L4S - aware AQM such as DualPI2, TCP Prague may occupy too much bandwidth. In addition, when the bottleneck is shared by a large amount of classical traffic, the performance of TCP Prague will also be affected.
These results indicate that **TCP Prague cannot guarantee that it will not harm other traffic or be harmed itself in all cases**. Therefore, when deciding whether to adopt L4S - compatible congestion control, it is necessary to carefully consider the specific network environment and traffic types.
### Summary
The paper reveals the potential problems of L4S - compatible congestion control in the partially - deployed environment by conducting a detailed evaluation of the performance of TCP Prague and BBRv2 under different network conditions. This provides an important reference for the gradual promotion of L4S technology in the future and also points out the direction for further optimization.