LEDBAT++: Congestion Control for Background Traffic

Operating systems and applications use background connections for a variety of tasks, such as software updates, large media downloads, telemetry, or error reporting. These connections should operate without affecting the general usability of the system. Usability is measured in terms of available network bandwidth and network latency. LEDBAT is designed to minimize the impact of lower than best effort connections on the latency and bandwidth of other connections. To achieve that, each LEDBAT connection monitors the delay experienced by the packets it sends across an Internet path, and compares them to the minimum delay observed on the connection. The difference between the transmission delay and the minimum delay is used as an estimate of the queuing delay. If the queuing delay is above a target, LEDBAT directs the connection to reduce the bandwidth used by the flow. If the queuing delay is below the target, the connection is allowed to increase its transmission rate. The increase or decrease in the used bandwidth are proportional to the difference between the observed values and the target. LEDBAT reacts to packet losses and other congestion signals in the same way as standard TCP. However, there are a few issues that plague LEDBAT, some previously documented, and some discovered by experiments (see Section 3). LEDBAT++ specifies additional mechanisms (and in some cases deviates from) LEDBAT to overcome these problems. The remaining sections describe the problems and the mechanisms in detail. LEDBAT++ is defined for use with TCP and its use with other transports is out-of-scope of this specification. The consensus of the Internet Congestion Control Research Group (ICCRG) is to publish this document to encourage further experimentation and review of LEDBAT++. The objective of this RFC is to document LEDBAT++ modifications of the base LEDBAT implementation and encourage its use so the algorithm can be further verified and improved. This document is not an IETF product and is not a standard. The status of this document is experimental. In section 5 titled Experiment Considerations, we describe the purpose of the experiment and its current status.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in and .

This section lists some known LEDBAT issues from existing literature and also list some new problems observed as a result of experimentation with an implementation of .

Delay based congestion control protocols like LEDBAT are known to suffer from a latecomer advantage. When the newcomer establishes a connection, the transmission delay that it encounters includes any queuing delay caused by existing connections that share common network queues. The newcomer considers this delay, that is larger than the base delay, the minimum, and thereby increases its transmission rate while other LEDBAT connections slow down. Eventually, the latecomer will result in using the entire bandwidth available to the connection. Standard TCP congestion control as described in and , causes some queuing, the LEDBAT delay measurements incorporate that queuing, and the base delay as measured by the connection is thus set to a larger value than the actual minimum. As a result, the queues remain mostly full. In some cases, this queuing persists even after the closing of the competing TCP connection. This phenomenon was already known during the design of LEDBAT, but there is no mitigation in the LEDBAT design. The designers of the protocol relied instead on the inherent burstiness of network traffic. Small gaps in transmission schedules would allow the latecomer to measure the true delay of the connection. This reasoning is not satisfactory because workloads can upload large amount of data, and would not always see such gaps.

The latecomer advantage is caused by the improper evaluation of the base delay, with the latecomer using a larger value than the preexisting connections. However, even when all competing connections have a correct evaluation of the base delay, some of them will receive a larger share of resources. The reason for that persistent unfairness is explained in . LEDBAT specifies proportional feedback based on a ratio between the measured queuing delay and a target. Proportional feedback uses both additive increases and additive decreases. This does stabilize the queue sizes, but it does not guarantee fair sharing between the competing connections.

LEDBAT estimates the base delay of a connection as the minimum of all observed transmission delays over a 10-minute interval. It uses an interval rather than a measurement over the whole duration of the connection, because network conditions may change over time. For example, an existing connection may be transparently rerouted over a longer path, with a longer transmission delay. Keeping the old estimate would then cause LEDBAT to unnecessarily reduce the connection throughput. However experiments show that this causes a ratcheting effect when LEDBAT connections are allowed to operate for a long time. The delay feedback in LEDBAT causes the queuing delay to stabilize just below the target. After an initial interval, all new measurements are equal to the initial transmission delay plus a fraction of the target. Every 10 minutes, the measured base delay increases by that fraction of the target queuing delay, leading to potentially large values over time.

LEDBAT compares the observed queuing delays to a fixed target. The target value cannot be set too low, because that would cause poor operation on slow networks (where the link transmission rate add a significant serialisation delay). In practice, it is set to 60ms, a value that allows proper operation of latency sensitive applications like VoIP. But if the bottleneck buffer is small such that the queuing delay will never reach the target, then the LEDBAT connection behaves just like an ordinary connection. It competes aggressively, and obtains the same share of the bandwidth as regular TCP connections. On high speed links the problem is exacerbated.

The LEDBAT algorithm requires use of one-way delay measurements. This makes it harder to use with transport protocols like TCP that have no reliable way to obtain one way delay measurements. TCP timestamps do not standardize clock frequency, and the endpoints will need to rely on heuristics to guess the clock frequency of the remote peer to detect and correct for clock skew. TCP timestamps do not include clock synchronization, and would need some non-standard invention to compensate for clock skew. Any such mechanism is very fragile.

When the measured delays are below the target delay, LEDBAT behaves like standard TCP . LEDBAT introduces a GAIN parameter which can be set between 0 and 1. In order to solve the low latency competition problem, LEDBAT++ makes the GAIN parameter dynamic. When standard and LEDBAT connections share the same bottleneck, they usually experience the same packet drop rate (i.e. when drop tail queues are used). The GAIN value ensures that the throughput of the LEDBAT++ connection will be a fraction (1/SQRT(1/GAIN)) of the throughput of the regular connections. Small values of GAIN work well when the base delay is small, and ensure that the LEDBAT++ connection will yield to regular connections in these networks. However, small values of GAIN do not work well on paths with long delays. In the absence of competing traffic, combining large base delays with small GAIN values causes the throughput used by the connection to remain well under capacity for a long time. In LEDBAT++, GAIN is a function of the ratio between the base delay and the target delay: GAIN = 1 / (min (16, CEIL (2*TARGET/base))) where CEIL(X) is defined as the smallest integer larger than X. Implementations MAY experiment with the constant value 1/16 as a tradeoff between responsiveness and performance.

suggests combining additive increases and multiplicative decreases in order to solve the Inter-LEDBAT fairness problem. It proposes to change the way LEDBAT increases and decreases the congestion window based on the ratio between the observed delay and the target. Assume that the congestion window is changed once per roundtrip measurement. In standard LEDBAT, the per RTT window when delay is less than target is: W += GAIN * (1 – delay/target) In LEDBAT++, with multiplicative decrease, the per RTT window when delay is less than target is: W += GAIN Similarly in standard LEDBAT, the per RTT window when the delay is higher than target is: W -= GAIN * (delay/target - 1) In LEDBAT++, with multiplicative decrease, the per RTT window delay is higher than target is: W += max( (GAIN – Constant * W * (delay/target - 1)), -W/2) ) It is RECOMMENDED that the Constant be set to 1. Implementations MAY experiment with this value. If a connection has various estimates of the base delay, the multiplicative decrease MUST be capped to at most W/2. Otherwise, spikes in delay can cause the window to immediately drop to its minimal value. LEDBAT++ sender SHOULD also ensure that the congestion window never decreases below 2 packets. This lower bound is intended to prevent starvation of the LEDBAT++ connection in the presence of transient congestion or delayed feedback. However, on severely constrained paths where the fair-share congestion window of competing flows may legitimately fall below two packets, enforcing such a bound could induce unnecessary queueing or congestion to itself and other flows.

Traditional initial slow start can cause spikes in bandwidth usage. However skipping exponential congestion window increase results in significantly reduced performance over long Internet Paths. LEDBAT++ applies the dynamic GAIN parameter to the congestion window increases. In standard TCP operation, the congestion window increases for every ACK by exactly the amount of bytes acknowledged. A LEDBAT++ sender increases the congestion window by that number multiplied by the dynamic GAIN value. In low latency links, this ensures that LEDBAT++ connections ramp up slower than regular connections. LEDBAT++ sender limits the initial window to 2 packets. LEDBAT++ sender monitors the transmission delays during the slow start period. If the queuing delay is larger than 3/4ths of the target delay, exit slow start and immediately move to the congestion avoidance phase. After initial slow start, the increase of congestion window is bounded by the SSTHRESH estimate acquired during congestion avoidance, and the risk of creating congestion spikes is very low. Exiting slow start on excessive delay SHOULD be applied only during the initial slow start.

The LEDBAT specification assumes that there will be natural gaps in the aggregated traffic through the bottleneck of the path, and that during those gaps the observed delay corresponds to a state where the queues are empty. However, there are workloads where the traffic is sustained for long periods. This causes base delay estimates to be inaccurate and is one of the major reasons behind latency drift as well as the lack of inter-LEDBAT fairness. To ensure stability, LEDBAT++ forces these gaps, or slow down periods. A slowdown is an interval during which the LEDBAT++ connection voluntarily reduces its traffic, allowing queues to drain and transmission delay measurements to converge to the base delay. The slowdown works as follows: Upon entering slowdown, set SSTHRESH to the current version of the congestion window CWND, and then reduce CWND to 2 packets. Keep CWND frozen at 2 packets for 2 RTT. After 2 RTT, ramp up the congestion window according to the slow start algorithm, until the congestion window reaches SSTHRESH. Keeping the CWND frozen at 2 packets for 2 RTT allows the queues to drain, and is key to obtaining accurate delay measurements. The initial slowdown starts shortly after the connection completes the initial slow start phase; 2 RTT after the initial slow start completes. After the initial slowdown, LEDBAT++ sender performs periodic slowdowns. The interval between slowdown is computed so that slowdown does not cause more than a 10% drop in the utilization of the bottleneck. LEDBAT++ sender measures the duration of the slowdown, from the time of entry to the time at which the congestion window regrows to the previous SSTHRESH value. The next slowdown is then scheduled to occur at 9 times this duration after the exit point. The combination of initial and periodic slowdowns allows competing LEDBAT connections to obtain good estimates of the base delay, and when combined with multiplicative decrease solves both the latecomer advantage and the Inter-LEDBAT fairness problems.

LEDBAT++ uses Round Trip Time measurements instead of one way delay. One possible shortcoming of round trip delay measurements is that they incorporate queuing delays in both directions. This can lead to unnecessary slowdowns, such as slowing down an upload connection because a download is saturating the downlink but in practice this seems to benefit the workloads because the bottleneck link can carry ACK traffic in the other direction for the competing flows. Round trip measurements also include the delay at the receiver between receiving a packet and sending the corresponding acknowledgement. These delays are normally quite small, except when the delayed acknowledgment logic kicks in. Effect of delayed ACKs can be particularly acute when the congestion window only includes a few packets, for example at the beginning of the connection. The problems of using one way delay are mitigated through a set of implementation choices. First, LEDBAT++ sender enables the TCP Timestamp option, in order to obtain RTT samples with each acknowledgement. A LEDBAT++ sender SHOULD filter the round trip measurements by using the minimum of the 4 most recent delay samples, as suggested in the LEDBAT specification. Finally, the queueing delay target is set larger than the typical TCP maximum acknowledgement delay. This avoids over reacting to a single delayed ACK measurement. The LEDBAT++ default delay target of 60ms is different from the 100ms value recommended in .

The status of this document is Experimental. The general purpose of the proposed experiment is to gain more experience running LEDBAT++ over different network paths to see if the proposed LEDBAT++ parameters perform well in different situations. Specifically, it is desirable to understand the following aspects of the LEDBAT++ mechanism: - The impact of transparent proxies which prevent measurement of end-to-end delay and might interfere with the effective operation of LEDBAT++. - Interaction between LEDBAT++ and Active Queue Management techniques such as Codel , PIE and L4S . - How the LEDBAT++ should resume after a period during which there was no incoming traffic and the information about the rLEDBAT state information is potentially dated. provides guidelines for the IETF to use when evaluating a proposed congestion control algorithm that differs from the general congestion control principles outlined in . The guidance and evaluation criteria is intended to be useful to authors proposing congestion control algorithms and for the IETF community when evaluating whether a proposal is appropriate for publication in the RFC Series and for deployment in the Internet.

LEDBAT++ is available in Microsoft's Windows 11 22H2 since October 2023 and in Windows Server 2022 since September 2022 . In addition, LEDBAT++ has been deployed by Microsoft in wide scale in the following services: - BITS (Background Intelligent Transfer Service) - DO (Delivery Optimization) service - Windows update # using DO - Windows Store # using DO - OneDrive - Windows Error Reporting # wermgr.exe; werfault.exe - System Center Configuration Manager (SCCM) - Windows Media Player - Microsoft Office - Xbox (download games) # using DO An experimental evaluation of the LEDBAT++ algorithm is presented in . Experiments involving the interaction of LEDBAT++ and BBR are presented in

LEDBAT++ enhances LEDBAT and inherits the general security considerations discussed in . LEDBAT++ uses the RTT measurements to modulate the rate of the sender. An attacker wishing to starve a flow can introduce an artificial delay to the packets either by actually delaying the packets. This would cause the LEDBAT++ receiver to believe that a queue is building up and reduce the congestion window. Note that an attacker to do that must be on path, so if that is the case, it is probably more direct to simply drop the packets and achieve even a larger window reduction.

This document has no actions for IANA.

The LEDBAT++ algorithm was designed and implemented by Osman Ertugay, Christian Huitema, Praveen Balasubramanian, and Daniel Havey. We would like to thank Reese Enghardt, Brian Trammell, Gorry Fairhurst and Ari Keranen for the review and comments on earlier versions of this document. This work was supported by the EU through the StandICT project RXQ.