TL;DR
This paper investigates whether users benefit from switching to TCP Prague in partial L4S deployments, revealing that TCP Prague may have less favorable fairness and throughput compared to traditional TCP variants in mixed environments.
Contribution
It provides an analysis of TCP Prague's performance and fairness in partial L4S deployments, highlighting potential barriers to its widespread adoption.
Findings
TCP Prague shows less favorable throughput in some coexistence scenarios.
Fairness between TCP Prague and non-L4S flows can be compromised.
Partial L4S deployment may hinder TCP Prague's adoption due to performance issues.
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.
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Code & Models
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
