The strict low-latency requirements of applications such as virtual reality, online gaming, etc., can not be satisfied by the current Internet. This is due to the characteristics of classic TCP such as Reno and TCP Cubic which induce high queuing delays when used for capacity-seeking traffic, which in turn results in unpredictable latency. The Low Latency, Low Loss, Scalable throughput (L4S) architecture addresses this problem by combining scalable congestion controls such as DCTCP and TCP Prague with early congestion signaling from the network. It defines a Dual Queue Coupled (DQC) AQM that isolates low-latency traffic from the queuing delay of classic traffic while ensuring the safe co-existence of scalable and classic flows on the global Internet. In this paper, we benchmark the DualPI2 scheduler, a reference implementation of DQC AQM, to validate some of the experimental result(s) reported in the previous works that demonstrate the co-existence of scalable and classic congestion controls and its low-latency service. Our results validate the co-existence of scalable and classic flows using DualPI2 Single queue (SingleQ) AQM, and queue latency isolation of scalable flows using DualPI2 Dual queue (DualQ) AQM. However, the rate or window fairness between DCTCP without fair-queuing (FQ) pacing and TCP Cubic using DualPI2 DualQ AQM deviates from the original results. We attribute the difference in our results and the original results to the sensitivity of the L4S architecture to traffic bursts and the burst sending pattern of the Linux kernel.

中文翻译：

---

验证 L4S 架构的共享行为和延迟特性

虚拟现实、网络游戏等应用对低延迟的严格要求，是目前互联网无法满足的。这是由于经典 TCP（例如 Reno 和 TCP Cubic）的特性在用于容量寻求流量时会导致高排队延迟，进而导致不可预测的延迟。低延迟、低损耗、可扩展吞吐量 (L4S) 架构通过将可扩展拥塞控制（例如 DCTCP 和 TCP 布拉格）与来自网络的早期拥塞信令相结合来解决此问题。它定义了一个双队列耦合（DQC）AQM，将低延迟流量与经典流量的排队延迟隔离开来，同时确保可扩展流量和经典流量在全球互联网上的安全共存。在本文中，我们对 DQC AQM 的参考实现 DualPI2 调度器进行了基准测试，验证以前工作中报告的一些实验结果，这些结果证明了可扩展和经典拥塞控制及其低延迟服务的共存。我们的结果验证了使用 DualPI2 单队列 (SingleQ) AQM 的可扩展流和经典流的共存，以及使用 DualPI2 双队列 (DualQ) AQM 的可扩展流的队列延迟隔离。但是，没有公平队列 (FQ) 起搏的 DCTCP 和使用 DualPI2 DualQ AQM 的 TCP Cubic 之间的速率或窗口公平性与原始结果有偏差。我们将结果与原始结果的差异归因于 L4S 架构对流量突发的敏感性和 Linux 内核的突发发送模式。