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 peaks. This results in queuing delay. As more and more internet applications require low latency, this is a problem that is only expected to increase. This includes not only video calling and e-sports, but also remote desktops, video streaming, remotely controlled devices, and numerous other technologies that are currently not feasible due to delays that often run into tens of milliseconds or more. With current technologies, even in well-configured networks, latency typically increases when there are long data streams, causing buffers to fill up and the user experience to deteriorate.
To address this problem and the associated challenges, a new architecture has been developed with accompanying technologies that offer low latency, minimal packet loss, and scalable throughput via the L4S internet standards. The L4S architecture is intended to enable an incremental rollout of scalable congestion control mechanisms. Scalable Congestion Control (CC), such as Data Center TCP (DCTCP), which is already used in data centers, and Immediate Active Queue Management (AQM) have been reused for this purpose.
DCTCP and the concept of scalability
DCTCP is scalable, unlike "non-scalable" classic 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 line 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 classic congestion control, which recovers through an additive process whereby one packet is added to the congestion window for each positive ACK. As a result, classic CC mechanisms take longer to recover at higher throughput. Although DCTCP is already in use as scalable CC, it cannot be rolled out on the public internet because it would crowd out classic traffic at shared bottlenecks and also 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 essential functionalities that are necessary 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 rolled out that claim to meet these requirements and achieve consistent low latency and full throughput utilization, there is a need for an in-depth, comparative evaluation. To the authors' knowledge, no comparative evaluation has yet been performed, nor has any comparison been made with classic 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?"
