| Internet-Draft | rLEDBAT | February 2025 |
| Bagnulo | Expires 9 August 2025 | [Page] |
This document specifies rLEDBAT for QUIC, a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for QUIC at the receiver end. This draft explores adaptation strategies for integrating rLEDBAT with QUIC's framework, aiming to maintain compatibility with QUIC.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 9 August 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
QUIC [RFC9000] is a transport protocol designed to provide fast connection establishment, multiplexed streams without head-of-line blocking, and built-in encryption using TLS 1.3. QUIC operates over UDP, allowing it to function efficiently even in environments with high latency or packet loss. With its user-space implementation and flexible congestion control mechanisms, QUIC has been widely adopted for web traffic, including HTTP/3.¶
Receiver-driven Low Extra Delay Background Transport (rLEDBAT)[I-D.irtf-iccrg-rledbat] is a congestion control mechanism designed for background data transfers in TCP. By leveraging delay-based congestion signals, rLEDBAT enables a receiver to control the sender's transmission rate to minimize interference with foreground traffic. This approach ensures that background transfers utilize available bandwidth without degrading the performance of latency-sensitive applications. rLEDBAT achieves this by dynamically adjusting the receiver's advertised window, effectively signaling the sender to slow down when network delays increase. rLEDBAT has been adopted for background traffic, including software updates, backups and prefetching.¶
The goal of this document is to define how rLEDBAT can be adapted for QUIC. Unlike TCP, QUIC does not expose the receiver's advertised window in the same way, requiring a different approach for implementing receiver-driven congestion control. This draft explores possible mechanisms to extend rLEDBAT for QUIC . The proposed design aims to support background data transfers in QUIC without introducing excessive network latency or disrupting higher-priority traffic.¶
In order to enable a QUIC receiver to execute rLEDBAT, we need to devise the means for the QUIC receiver to feed information about the delay and packet loss to the LBE congestion control algorithm executed at the receiver. In addition, the LBE congestion control algorithm produces a congestion window value as an output which is to be used by the QUIC receiver to modulate the rate at which the QUIC sender is transmitting. We need to analyze how all this can be accomplished.¶
A QUIC receiver can measure the RTT passively or actively. Passive measurements of the RTT can be done by simply measuring the RTT of the exchange packets. In the QUIC protocol, all packets exchanged are acknowledged, so simply matching the packet sent by the receiver and the ACK frame generated by the sender allows the receiver to passively measure the RTT.¶
There is, however, a potential problem. RFC 9002 [RFC9002] explicitly states that an incoming ACK frame should be used to compute the RTT if and only if the following two conditions are met: (i) the largest acknowledged packet number is newly acknowledged, and (ii) at least one of the newly acknowledged packets was ack-eliciting.¶
Unfortunately, a common use case for rLEDBAT is the one where the receiver is downloading a large file from the sender, meaning that the receiver is not sending any data and, as such, is only generating non-ack-eliciting frames (i.e., it is only generating ACK frames from the incoming data). The reason for such a recommendation is that ACKs for non-ack-eliciting frames can be arbitrarily delayed, as the receiver of such frames is not required to issue the corresponding ACK frame within a certain time bound (which is the case for ack-eliciting frames).¶
This is similar to what happens in rLEDBAT for TCP, and the discussion presented in Section 3.2.1.1 of the rLEDBAT for TCP draft holds. That is, in the common use case for rLEDBAT, the sender is transmitting a large file, so, in general, it will have data to send, enabling an accurate measurement of the RTT most of the time. Similar considerations also apply, namely, the rLEDBAT receiver should apply a minimum filter when estimating the RTT in order to discard large samples caused by periods in which the sender has no data to send. Also, in cases where it is the flow control exerted by the receiver that is preventing the sender from sending more data, the sender should discard samples generated while reducing the sender's window through flow control.¶
QUIC allows the sender of an ACK frame to report any additional delay that the issuer has incurred before returning the ACK. This can be used to correct the RTT computation by discounting the reported delay in the RTT estimation. While this is straightforward for ack-eliciting frames, it is less so for non-ack-eliciting frames.¶
The ACK for a non-ack-eliciting frame is included in the next ack-eliciting packet generated. It is unclear whether the value reported in the ACK delay field of such an ACK frame includes all the time since the packet was received and the ACK was issued. If so, then this can help to correct the RTT computation. If not, then it is uncertain what value of ACK delay these frames include, if any.¶
This then creates another question: if these frames include an unusable value for the ACK delay, should the receiver use the ACK delay value included in the ACK for the ack-eliciting frames? The problem is that making corrections for some of the samples and not for others will distort the RTT estimation.¶
A QUIC receiver can also perform active measurements to measure the RTT. The QUIC protocol includes PING frames that require the receiver to respond with an ACK frame. The receiver can periodically generate PING frames and compute the RTT using those. The receiver should then issue several (3?) PING frames every RTT to allow a robust measurement of the RTT, even if one or more of such PING frames are lost.¶
The benefit of this approach is that it provides accurate RTT measurements, irrespective of the traffic pattern generation of the sender. The downside is that it requires extra logic to generate these PING frames and requires extra link capacity and processing to handle them.¶
A QUIC rLEDBAT receiver can detect packet loss through retransmission of data. For that, the receiver inspects the received data frames and detects a retransmission as follows: suppose that X is the largest offset corresponding to data received so far (not necessarily all data corresponding to a smaller offset was received already), and Y is the largest packet number in the application data space for a packet received so far. A packet with packet number m and including a data frame with offset n is a retransmission if m > Y and n < X.¶
The QUIC receiver can control the sender's rate using the MAX_DATA frame. The MAX_DATA frame carries the amount of data that can be sent in that connection, across all streams. A QUIC receiver with rLEDBAT enabled will convey the congestion window computed by the LEDBAT++ algorithm running in the receiver using the MAX_DATA frame.¶
Similarly to the case of TCP, a QUIC rLEDBAT receiver should refrain from shrinking the announced value. While it is not an error, it will not have any effect on the sender. So, again similarly to the case of TCP, the QUIC rLEDBAT receiver should only reduce the announced value in the amount of bytes acknowledged.¶
TBD¶
No actions are required from IANA.¶
This work was supported by the EU through the StandICT project RXQ.¶