arXiv subjects
Publications and source records attributed to Bob Briscoe.
This memo defines a brief set of tests to determine the decapsulation behaviour of an unknown remote tunnel endpoint with respect to the Explicit Congestion Notification (ECN) field in the Internet Protocol (IP) header. The tests could be automated to be used by a tunnel ingress to determine whether the egress that it is paired with will propagate ECN correctly.
This paper aims to provide a robust grounding for the additive increase factor used in the `TCP-Friendly' mode of the CUBIC congestion control algorithm.
In the process of testing improvements to the Linux DCTCP code in various scenarios, we found different performance problems kept surfacing with no apparent pattern. This report records a systematic sequence of experiments designed to track down the causes of these problems, which were found to be due to a complex tangle of bugs and flaws. The report also provides and evaluates solutions in each case.
On the Internet, sub-millisecond queueing delay and capacity-seeking have traditionally been considered mutually exclusive. We introduce a service that offers both: Low Latency Low Loss Scalable throughput (L4S). When tested under a wide range of conditions emulated on a testbed using real residential broadband equipment, queue delay remained both low (median 100--300 $\mu$s) and consistent (99th percentile below 2 ms even under highly dynamic workloads), without compromising other metrics (zero congestion loss and close to full utilization). L4S exploits the properties of `Scalable' congestion controls (e.g., DCTCP, TCP Prague). Flows using such congestion control are however very aggressive, which causes a deployment challenge as L4S has to coexist with so-called `Classic' flows (e.g., Reno, CUBIC). This paper introduces an architectural solution: `Dual Queue Coupled Active Queue Management', which enables balance between Scalable and Classic flows. It counterbalances the more aggressive response of Scalable flows with more aggressive marking, without having to inspect flow identifiers. The Dual Queue structure has been implemented as a Linux queuing discipline. It acts like a semi-permeable membrane, isolating the latency of Scalable and `Classic' traffic, but coupling their capacity into a single bandwidth pool. This paper justifies the design and implementation choices, and visualizes a representative selection of hundreds of thousands of experiment runs to test our claims.
This report gives the reasoning for the setting of the target queue delay parameter in the reference Linux implementation of PI$^2$ Active Queue Management (AQM)
This report explains how DCTCP takes 2--3 rounds before it even starts to respond to congestion. This is due to the clocking machinery in its moving average of congestion feedback. Instead, per-ACK mechanisms are proposed, which cut out all the extra lag, leaving just the inherent single round of feedback delay. Even though clocking per ACK updates the average much more frequently, it is arranged to inherently smooth out variations over the same number of round trips, independent of the number of ACKs per round. Evaluation of the v02 algorithm found design errors. This version (v04) is published prior to evaluation, in order to elicit early feedback on the design.
The IETF's Prague L4S Requirements [DSBE20] expect an L4S congestion control to somehow detect if there is a classic ECN [RFB01] AQM at the bottleneck and fall back to Reno-friendly behaviour (as it would on a loss). This paper addresses that requirement in depth. A solution has been implemented in Linux and extensively tested, which distinguishes L4S from Classic AQMs primarily by their delay variation. This paper describes version 2 of the design of that solution, giving extensive rationale and pseudocode. It briefly summarizes a comprehensive testbed evaluation of the solution, referring to the full details online. The v2 algorithm very rarely falsely detects a Classic AQM as L4S. It also rarely detects an L4S AQM as Classic in the majority of scenarios, but not at low link rates and large RTTs. This report is a work in progress. It suggests ideas for improving on the approach. It also outlines new ideas that could solve the problem in complementary or alternative ways.
This memo explains that deploying active queue management (AQM) to counter bufferbloat will not prevent TCP from overriding the AQM and building large queues in a range of not uncommon scenarios. This is a brief paper study to explain this effect which was observed in a number of low latency testbed experiments. To keep its queue short, an AQM drops (or marks) packets to make the TCP flow(s) traversing it reduce their packet rate. Nearly all TCP implementations will not run at less than two packets per round trip time (RTT). 2pkt / RTT need not imply low bit-rate if the RTT is small. For instance, it represents 2Mb/s over a 6ms round trip. When a few TCP flows share a link, in certain scenarios, including regular broadband and data centres, no matter how much the AQM signals to the flows to keep the queue short, they will not obey, because it is impossible for them to run below this floor. The memo proposes the necessary modification to the TCP standard.
Low Latency, Low Loss Scalable throughput (L4S) is being proposed as the new default Internet service. L4S can be considered as an `incrementally deployable clean-slate' for new Internet flow-rate control mechanisms. Because, for a brief period, researchers are free to develop host and network mechanisms in tandem, somewhat unconstrained by any pre-existing legacy. Scaling requirements represent the main constraints on a clean-slate design space. This document confines its scope to the steady state. It aims to resolve the tensions between a number of apparently conflicting scalability requirements for L4S congestion controllers. It has been produced to inform and provide structure to the debate as researchers work towards pre-standardization consensus on this issue. This work is important, because clean-slate opportunities like this arise only rarely and will only be available briefly---for roughly one year. The decisions we make now will tend to dirty the slate again, probably for many decades.
Rather than directly considering the queuing delay of data, this memo focuses on reducing the delay that congestion signals experience within a queue management algorithm, which can be greater than the delay that the data itself experiences within the queue. Once the congestion signals are delayed, regulation of the load becomes more sloppy, and the queue tends to overshoot and undershoot more as a result, leading the data itself to experience greater peaks in queuing delay as well as intermittent under-utilization. Where the service rate of a queue varies, it is preferable to measure the queue in units of time not bytes. However, the size of the queued backlog can be measured in bytes and signalled at the last instant as data leaves the queue, whereas measuring queuing delay introduces inherent delay. This paper proposes 'scaled sojourn time', which scales queuing delay by the ratio between the backlogs at dequeue and enqueue. This is equivalent to scaling the sojourn time by the ratio of the arrival and departure rates averaged over the time spent in the queue. The paper also proposes the removal of delays due to randomness in the signal encoding.
This memo focuses solely on the native AQM of Low Latency Low Loss Scalable throughput (L4S) traffic and proposes various improvements to the original step design. One motivation for DCTCP to use simple step marking was that it was possible to deploy it by merely configuring the RED implementations in existing hardware, albeit in an unexpected configuration by setting parameters to degenerate values. However, there is no longer any imperative to stick with the original DCTCP step-function design, because changes will be needed to implement the DualQ Coupled AQM anyway, and the requirements for L4S congestion controls are not yet set in stone either. This paper proposes gradient (ramp) marking and a virtual (a.k.a. phantom) queue. It provides a way to implement virtual queuing delay (a.k.a. virtual sojourn time) and scaled virtual sojourn time.
Active queue management (AQM) drops packets early in the growth of a queue, to prevent a capacity-seeking sender (e.g. TCP) from keeping the buffer full. An AQM can mark instead of dropping packets if they indicate support for explicit congestion notification (ECN). Two modern AQMs (PIE and CoDel) are designed to keep queuing delay to a target by dropping packets as load varies. This memo uses Curvy RED and an idealised but sufficient model of TCP traffic to explain why attempting to keep delay constant is a bad idea, because it requires excessively high drop at high loads. This high drop itself takes over from queuing delay as the dominant cause of delay, particularly for short flows. At high load, a link is better able to preserve reasonable performance if the delay target is softened into a curve rather than a hard cap. The analysis proves that the same AQM can be deployed in different parts of a network whatever the capacity with the same optimal configuration. A surprising corollary of this analysis concerns cases with a highly aggregated number of flows through a bottleneck. Although aggregation reduces queue variation, if the target queuing delay of the AQM at that bottleneck is reduced to take advantage of this aggregation, TCP will still increase the loss level because of the reduction in round trip time. The way to resolve this dilemma is to overprovision (a formula is provided). Nonetheless, for traffic with ECN enabled, there is no harm in an AQM holding queuing delay constant or configuring an AQM to take advantage of any reduced delay due to aggregation without over-provisioning. Recently, the requirement of the ECN standard that ECN must be treated the same as drop has been questioned. The insight that the goals of an AQM for drop and for ECN should be different proves that this doubt is justified.
This memo proposes to transplant the core idea of Curvy RED, the softened delay target, into AQMs that are better designed to deal with dynamics, such as PIE or PI2, but that suffer from the weakness of a fixed delay target.