Implementing the ’ Prague Requirements ’ for Low Latency Low Loss Scalable Throughput ( L 4 S )

This paper is about a new approach for ultra-low queuing delay for all Internet traffic. ’Ultra-low queuing’ means a few hundred microseconds of queuing delay on average, and about 1ms at the 99th percentile. This is 10 times better than state-of-the-art AQMs (FQ-CoDel and PIE). And all traffic means not just low rate VoIP, gaming, etc. but also capacityseeking TCP-like applications. It is achieved by addressing the root cause of the problem—the congestion controller at the source. The solution is to use one of the family of ’scalable’ congestion controls. The talk will explain what that means, but for now it will suffice to say that Data Centre TCP (DCTCP) is an example. But there are other examples, including a scalable congestion control for real-time media. So the task has been to make it possible and safe to incrementally deploy congestion controls like DCTCP over the public Internet. The whole architecture is called Low Latency Low Loss Scalable throughput (L4S). Although this all sounds rather grandiose, it actually only involves a few incremental changes to code in hosts and network nodes. You will recognise some of these, because most are desirable in themselves, and already in progress (e.g. Accurate ECN and RACK). However, focusing on all the parts loses sight of the sum. So this paper starts by explaining the sum of the parts the bigger motivation for all the changes together. Then the body of the paper dives into the changes to DCTCP needed to make it safely coexist with other traffic, and to improve performance when used over the Internet—to satisfy the ‘Prague L4S Requirements’. The resulting TCP implementation is called TCP Prague. ∗Independent †Nokia Bell-Labs ‡ETH Zürich §Department of Informatics, University of Oslo ¶Simula Research Laboratory 1 Low Delay and High Bandwidth Traditionally it has been believed that capacity-seeking applications (TCP-like) always build a queue so they cannot have extremely low (sub-millisecond) queuing delay. This has led to the mistaken idea that an application fundamentally cannot have both ultra-low latency and maximal throughput. With L4S every application can have both. It is ultimately intended to replace ’best efforts’ as the new default Internet service. Not only does L4S remove all the unnecessary and variable lag from today’s applications (e.g. gaming, everything on the web, video chat), but it also enables tomorrow’s applications that need both high bandwidth and extremely low delay. For instance, high definition video conferencing and video chat, cloud-rendered interactive video, cloud-rendered virtual reality, augmented reality, remote presence with remote control, and others yet to be invented. The L4S architecture [9] is in the late stages of standardization on the IETF’s experimental track. it involves incremental changes to hosts and network [14, 13]. Both parts of L4S are in large part integrations of existing tried and tested pieces. The aim has been to minimize risk and to ease incremental deployment but to still achieve radically better performance. Back in summer 2015, the day after the first demonstration of applications using L4S over a DSL broadband link, 30-odd DCTCP-folks got together during the IETF in Prague and agreed a prioritized set of changes to DCTCP that would be needed to deploy it over the public Internet. The list was dubbed the ’TCP Prague requirements’, which were subsequently written into an IETF spec. They have since been renamed the Prague L4S Requirements, because they also apply to UDP-based transports. This paper introduces the important components of the first ’TCP Prague’ implementation to satisfy these requirements, which has been open-sourced in Linux. As well as outlining rationale, it explains how to use it and gives the maturity of each component implementation, plus some points