Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

To Switch or Not to Switch to TCP Prague? Incentives for Adoption in a Partial L4S Deployment

Fatih Berkay Sarpkaya, Ashutosh Srivastava, Fraida Fund, Shivendra Panwar

TL;DR

The paper addresses whether unilateral adoption of TCP Prague yields benefits in a partial L4S deployment where Prague coexists with non-L4S congestion controls. It conducts FABRIC-based experiments across diverse bottleneck queueing configurations and classic CCs to quantify throughput and latency. The results reveal that Prague's performance is sensitive to the bottleneck queueing discipline and ECN signaling, with potential starvation or dominance in several scenarios, and that ECN fallback and DualPI2 have mixed effects. These insights inform content providers and standards bodies about the incentives and risks of incremental L4S deployment and point to the need for robust coexistence mechanisms to enable safe, scalable rollout.

Abstract

The Low Latency, Low Loss, Scalable Throughput (L4S) architecture has the potential to reduce queuing delay when it is deployed at endpoints and routers throughout the Internet. However, it is not clear how TCP Prague, a prototype scalable congestion control for L4S, behaves when L4S is not yet universally deployed. Specifically, we consider the question: in a partial L4S deployment, will a user benefit by unilaterally switching from the status quo TCP to TCP Prague? To address this question, we evaluate the performance of a TCP Prague flow when sharing an L4S or non-L4S bottleneck queue with a non-L4S flow. Our findings suggest that the L4S congestion control, TCP Prague, has less favorable throughput or fairness properties than TCP Cubic or BBR in some coexistence scenarios, which may hinder adoption.

To Switch or Not to Switch to TCP Prague? Incentives for Adoption in a Partial L4S Deployment

TL;DR

The paper addresses whether unilateral adoption of TCP Prague yields benefits in a partial L4S deployment where Prague coexists with non-L4S congestion controls. It conducts FABRIC-based experiments across diverse bottleneck queueing configurations and classic CCs to quantify throughput and latency. The results reveal that Prague's performance is sensitive to the bottleneck queueing discipline and ECN signaling, with potential starvation or dominance in several scenarios, and that ECN fallback and DualPI2 have mixed effects. These insights inform content providers and standards bodies about the incentives and risks of incremental L4S deployment and point to the need for robust coexistence mechanisms to enable safe, scalable rollout.

Abstract

The Low Latency, Low Loss, Scalable Throughput (L4S) architecture has the potential to reduce queuing delay when it is deployed at endpoints and routers throughout the Internet. However, it is not clear how TCP Prague, a prototype scalable congestion control for L4S, behaves when L4S is not yet universally deployed. Specifically, we consider the question: in a partial L4S deployment, will a user benefit by unilaterally switching from the status quo TCP to TCP Prague? To address this question, we evaluate the performance of a TCP Prague flow when sharing an L4S or non-L4S bottleneck queue with a non-L4S flow. Our findings suggest that the L4S congestion control, TCP Prague, has less favorable throughput or fairness properties than TCP Cubic or BBR in some coexistence scenarios, which may hinder adoption.
Paper Structure (5 sections, 4 figures, 1 table)

This paper contains 5 sections, 4 figures, 1 table.

Table of Contents

  1. Introduction
  2. Background
  3. Experiment Methodology
  4. Experiment Results
  5. Conclusion

Figures (4)

  • Figure 1: Fundamental Problem of Classic Congestion Control. Adapted from prague-paper, we conduct a FABRIC experiment using a line network with 100 Mbps bottleneck capacity, a base RTT of 25 ms, and a buffer size of 2 BDP. The bottleneck AQM is FIFO with ECN. The artifacts to reproduce this experiment are available in github.
  • Figure 2: Experiment Topology
  • Figure 3: Prague throughput (Mbps) when sharing 100 Mbps bottleneck with Cubic flow.
  • Figure 6: Prague throughput and queuing delay, sharing a 100 Mbps bottleneck with an AccECN BBRv2 flow.