To Switch or Not to Switch to TCP Prague?

What is it about?

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 (classic) 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 other variants of TCP like TCP Cubic or BBR in some coexistence scenarios, which may hinder adoption.

Featured Image

Photo by Alina Grubnyak on Unsplash

Photo by Alina Grubnyak on Unsplash

Why is it important?

To further the adoption of low-latency applications such as Augmented Reality or Cloud Games on the Internet, it is important to reducing queuing delay at bottlenecks. TCP Prague, a component of L4S, has gained traction as a transport layer technique to achieve this goal. It will, however, need to share resources with other variants of TCP (the classic versions) when TCP Prague traffic is not segregated. This paper examines coexistence scenarios, and the results show TCP Prague does not work well in such scenarios.