TCP Prague Evaluation
The majority of internet traffic is capacity-seeking, meaning flows aim to maximize their bandwidth using available capacity, including large buffers designed to absorb bursts of data. However, this behavior results in queuing delays, which is increasingly problematic as more internet applications require low latency. Technologies such as video calling, e-sports, remote desktops, video streaming, and remote-controlled devices demand fast response times, yet many of these technologies are hindered by delays commonly in the tens of milliseconds or more.
Using current technologies, even on well-configured networks, delays typically increase when long-running flows fill buffers, leading to a degraded user experience. To address this issue, a new architecture and accompanying technologies were developed to provide lower latency, minimal packet loss, and scalable throughput through the L4S internet standards. The L4S architecture aimed to enable the incremental deployment of scalable congestion controls, repurposing Scalable Congestion Control (CC) methods such as Data Center TCP (DCTCP) and immediate Active Queue Management (AQM)
TCTCP Multiplicative recovery
DCTCP was designed as a scalable alternative to “non-scalable” classic congestion control mechanisms like Cubic, Reno, and BBR. A congestion controller is considered scalable if the rate of congestion signals per round trip scales with changes in the bandwidth-delay product (BDP or window). Unlike classical congestion control, which uses additive recovery (adding one packet to the congestion window for each positive ACK received), DCTCP employs multiplicative recovery, allowing it to recover quickly after packet loss even as throughput increases. While DCTCP is already used within data centers, it cannot currently be deployed on the public internet as it would starve classic traffic sharing the same bottleneck and poses security risks.
Despite the significant benefits offered by scalable congestion controls, a complete transition to them was not immediately feasible. These new mechanisms needed to coexist with classical congestion control protocols without gaining an unfair advantage. Scalable TCP variants, for instance, use a more fine-grained control scheme that reacts less aggressively to congestion notifications, giving them an edge over older protocols like Reno and Cubic.
To guide the development of scalable congestion control mechanisms, a framework known as the “Prague requirements” was established. These requirements outlined essential functionalities necessary to improve upon classical congestion control while addressing the limitations of DCTCP. The L4S architecture, which supports these requirements, was under standardization by the IETF.
As implementations of these scalable congestion control mechanisms were rolled out, claiming to fulfill the Prague requirements and achieve consistently low latency and full throughput utilization, there was a need for a detailed comparative evaluation. No prior assessment had been conducted to compare these implementations with one another and with classic congestion control protocols. Such an evaluation was essential to ensure fairness, address coexistence challenges between scalable and non-scalable TCP traffic, and maintain equal access to the internet for all users.
This research provided a comparative analysis of scalable congestion control mechanisms and their implementations, assessing their performance against each other and traditional protocols. The study sought to verify whether the Prague requirements were met and to ensure that the new mechanisms could coexist fairly with older congestion control approaches, ultimately contributing to a balanced and efficient internet infrastructure.