Papers › To Switch or Not to Switch to TCP Prague? Incentives for Adoption in a Partial L4S Deployment
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
The archive published only this paper's code-link row. Authors, date and abstract are from arXiv's metadata (CC0), read from the Kaggle arXiv metadata snapshot of 2026-09-12 where its title matched the archive's; the title is the archive's.
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.
Code
Repository list and official/mentioned flags are the archive's, frozen 2025-07-28. Reachability, where shown, is from one Syntology probe window (2026-09-16 to 2026-09-18); repositories not probed show nothing. GitHub stars are not tracked.
Code Syntology ran Syntology
Not run by Syntology. Nothing on this page verifies that the listed code works.
Results from the paper archive 2025-07-28
No leaderboard rows for this paper in the archive.
Report a problem or propose a change · a person checks every report against the paper or source before anything changes; decisions are listed on /corrections