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

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.