Evaluation of TCP Prague implementation
The majority of the traffic going through the internet is capacity-seeking. This means that those flows will maximise their bandwidth using the available capacity, including utilising large buffers whose purpose is to absorb bursts. In consequence this creates queuing delay. Since an increasing amount of our Internet applications need low latency, this is a problem that is expected to get worse. It is not only video calling and e-sport that need fast response times but also remote desktops, video streaming, remote-controlled devices and much more technologies that are not viable yet due to delays commonly in the tens of milliseconds or more. Using today’s technologies, when long-running flows are present even on a well configured network, the delay usually increases due to buffer filling up, providing a degraded experience for the user. To address this problem and its many aspects, a new architecture and respective technologies are build to offer lower latency, low loss and scalable throughput, through the L4S internet standards. The L4S architecture is intended to enable incremental deployment of scalable congestion controls. Scalable Congestion Control (CC) such as Data Center TCP (DCTCP), already used within data centers, and immediate Active Queue Management (AQM) have been repurposed towards this direction.
DCTCP is scalable as opposed to “non-scalable” classic congestion control mechanisms such as Cubic, Reno, BBR, etc. A congestion controller is scalable if the rate of the congestion signals per round trip scales together with bandwidth-delay product (BDP or window) changes. As the throughput increases, the time for the DCTCP to recover after a packet loss does not increase thanks to its multiplicative recovery. This is in contrast to classical congestion control that recovers using a additive process by adding one packet to the congestion window for every positive ACK received. Therefore, classical CC will take more time to recover when the throughput is higher. Contrary to other scalable algorithms. DCTCP is already in use as a scalable CC but cannot be deployed on the public internet as it would starve classic traffic sharing the same bottleneck and it poses security problems.
Although this new generation of congestion controls bring significant benefits, due to the aforementioned reasons, it is not possible to switch to them overnight. Such CCs must be able to work in concert with previous generation ones without getting an unfair advantage. Indeed, as scalable TCP variants have a more fine-grained control scheme, they react less aggressively to congestion notification and therefore would outcompete older variants such as Reno and Cubic. In order to provide a framework for these new CC mechanisms, a list of requirements – known as the “Prague requirements” – were set. These constitute a list of essential functionalities that need to be fulfilled to properly improve on existing classical congestion control and avoid the pitfalls of DCTCP. The L4S architecture on which the Prague requirements rely, is under standardisation process by the IETF. As respective implementations are being rolled out that claim to follow these requirements and achieve consistently low latency and full throughput utilisation, there is a need for a comparative in depth evaluation. No assessment against each other and against classic congestion control has been performed, to the knowledge of the authors. This is needed e.g., to ensure fairness, addressing the coexistence problem between scalable and non-scalable TCP traffic or between scalable CC implementations, ensuring equal access to the internet for everyone. Therefore, this research focused on the evaluation of the TCP Prague implementations with the following research question:
- Are the current TCP Prague implementations standard compliant?
