Evaluation of the TCP Prague implementation
The majority of Internet traffic is capacity-seeking. This means that these data streams maximize their bandwidth within the available capacity, including utilizing large buffers intended to absorb traffic spikes. As a result, this leads to queuing delay. Since more and more Internet applications require low latency, this is a problem that is expected to only grow. This applies not only to video calls and esports, but also to remote desktops, video streaming, remotely controlled devices, and numerous other technologies that are currently not fully feasible due to delays that often reach tens of milliseconds or more. With current technologies, even in well-configured networks, latency typically increases as soon as there are sustained data streams: buffers fill up and the user experience deteriorates.
To address this problem and the associated challenges, a new architecture has been developed, along with supporting technologies that offer low latency, minimal packet loss, and scalable throughput via the L4S Internet standards. The L4S architecture is designed to enable the incremental deployment of scalable congestion control mechanisms. Scalable Congestion Control (CC), such as Data Center TCP (DCTCP)—which is already in use within data centers—and Immediate Active Queue Management (AQM) have been repurposed for this purpose.
DCTCP and the concept of scalability
DCTCP is scalable, unlike “non-scalable” classical congestion control mechanisms such as Cubic, Reno, and BBR. A congestion controller is scalable when the frequency of congestion signals per round trip increases in tandem with changes in the bandwidth-delay product (BDP or window). As throughput increases, DCTCP’s recovery time after packet loss does not increase, thanks to its multiplicative recovery mechanism. This contrasts with classical congestion control, which recovers via an additive process in which one packet is added to the congestion window for each positive ACK. As a result, classical CC mechanisms take longer to recover at higher throughput. Although DCTCP is already in use as a scalable congestion control mechanism, it cannot be deployed on the public Internet because it would crowd out conventional traffic at shared bottlenecks and, moreover, poses security risks.
The Prague requirements and L4S standardization
Although this new generation of congestion control mechanisms offers significant advantages, an immediate switch is not feasible. Such CCs must be able to work together with older variants without gaining an unfair advantage. Because scalable TCP variants apply finer-grained congestion control, they respond less aggressively to congestion signals and would outperform older variants such as Reno and Cubic. To provide a framework for this, a set of requirements has been drawn up, known as the "Prague requirements." These describe the essential functions required to improve classic congestion control and avoid the pitfalls of DCTCP.
The L4S architecture on which the Prague requirements are based is currently undergoing standardization at the IETF. Now that implementations are being deployed that claim to meet these requirements and achieve consistently low latency and full throughput utilization, there is a need for an in-depth, comparative evaluation. To the best of the authors’ knowledge, no such comparative evaluation has yet been conducted, nor has a comparison been made with classical congestion control. Such an analysis is necessary to ensure fairness, address coexistence issues between scalable and non-scalable TCP traffic, and guarantee equal access to the Internet.
Research objective
This study therefore focused on evaluating TCP Prague implementations with the following research question:
"Are current TCP Prague implementations compliant with the standard?"
