rLEDBAT: receiver-driven Low Extra Delay Background Transport for TCP

Abstract

This document specifies the rLEDBAT, a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for TCP at the receiver end.¶

1. Introduction

LEDBAT (Low Extra Delay Background Transport) [RFC6817] is a congestion-control algorithm that implements a less-than-best-effort (LBE) traffic class.¶

When LEDBAT traffic shares a bottleneck with one or more TCP connections using standard congestion control algorithms such as Cubic [RFC8312] (hereafter standard-TCP for short), it reduces its sending rate earlier and more aggressively than standard-TCP congestion control, allowing standard-TCP traffic to use more of the available capacity. In the absence of competing standard-TCP traffic, LEDBAT aims to make an efficient use of the available capacity, while keeping the queuing delay within predefined bounds.¶

LEDBAT reacts both to packet loss and to variations in delay. Regarding to packet loss, LEDBAT reacts with a multiplicative decrease, similar to most TCP congestion controllers. Regarding delay, LEDBAT aims for a target queueing delay. When the measured current queueing delay is below the target, LEDBAT increases the sending rate and when the delay is above the target, it reduces the sending rate. LEDBAT estimates the queuing delay by subtracting the measured current one-way delay from the estimated base one-way delay (i.e. the one-way delay in the absence of queues).¶

The LEDBAT specification [RFC6817] defines the LEDBAT congestion-control algorithm, implemented in the sender to control its sending rate. LEDBAT is specified in a protocol and layer agnostic manner.¶

LEDBAT++ [I-D.irtf-iccrg-ledbat-plus-plus] is also an LBE congestion control algorithm which is inspired in LEDBAT while addressing several problems identified with the original LEDBAT specification. In particular the differences between LEDBAT and LEDBAT++ include: i) LEDBAT++ uses the round-trip-time (RTT) (as opposed to the one way delay used in LEDBAT) to estimate the queuing delay; ii) LEDBAT++ uses an Additive Increase/Multiplicative Decrease algorithm to achieve inter-LEDBAT++ fairness and avoid the late-comer advantage observed in LEDBAT; iii) LEDBAT++ performs periodic slowdowns to improve the measurement of the base delay; iv) LEDBAT++ is defined for TCP.¶

In this note, we describe rLEDBAT, a set of mechanisms that enable the execution of an LBE delay-based congestion control algorithm such as LEDBAT or LEDBAT++ in the receiver end of a TCP connection.¶

The status of this document is experimental. In section 4 about Experiment Considerations we describe the purpose of the experiment and its current status.¶

2. Motivations for rLEDBAT

rLEDBAT enables new use cases and new deployment models, fostering the use of LBE traffic and benefitting the global Internet by improving overall allocation of resources. The following scenarios are enabled by rLEDBAT:¶

• Content Delivery Networks and more sophisticated file distribution scenarios: Consider the case where the source of a file to be distributed (e.g., a software developer that wishes to distribute a software update) would prefer to use LBE and it enables LEDBAT/LEDBAT++ in the servers containing the source file. However, because the file is being distributed through a CDN which surrogates do not support LBE congestion control, the result is that the file transfers, originated from CDN surrogates will not be using LBE. Interestingly enough, in the case of the software update, the developer may also control the software performing the download in the client, the receiver of the file, but because current LEDBAT/LEDBAT++ are sender-based algorithms, controlling the client is not enough to enable LBE congestion control in the communication. rLEDBAT would enable the use of LBE traffic class for file distribution in this setup.¶

• Interference from proxies and other middleboxes: Proxies and other middleboxes are a commonplace in the Internet. For instance, in the case of mobile networks, proxies are frequently used. In the case of enterprise networks, it is common to deploy corporate proxies for filtering and firewalling. In the case of satellite links, Performance Enhancement Proxies (PEPs) are deployed to mitigate the effect of the long delay in TCP connection. These proxies terminate the TCP connection on both ends and prevent the use of LBE congestion control in the segment between the proxy and the sink of the content, the client. By enabling rLEDBAT, clients would be able to enable LBE traffic between them and the proxy.¶

• Receiver-defined preferences. It is frequent that the bottleneck of the communication is the access link. This is particularly true in the case of mobile devices. It is then especially relevant for mobile devices to properly manage the capacity of the access link. With current technologies, it is possible for the mobile device to use different congestion control algorithms expressing different preferences for the traffic. For instance, a device can choose to use standard-TCP for some traffic and to use LEDBAT/LEDBAT++ for other traffic. However, this would only affect the outgoing traffic since both standard-TCP and LEDBAT/LEDBAT++ are sender-driven. The mobile device has no means to manage the traffic in the down-link, which is in most cases, the communication bottleneck for a typical eye-ball end-user. rLEDBAT enables the mobile device to selectively use LBE traffic class for some of the incoming traffic. For instance, by using rLEDBAT, a user can use regular standard-TCP/UDP for video stream (e.g., Youtube) and use rLEDBAT for other background file download.¶

3. rLEDBAT mechanisms

rLEDBAT provides the mechanisms to implement an LBE congestion control algorithm at the receiver-end of a TCP connection. The rLEDBAT receiver controls the sender's rate through the Receive Window announced to the receiver in the TCP header.¶

rLEDBAT assumes that the sender is a standard TCP sender. rLEDBAT does not require any rLEDBAT-specific modifications to the TCP sender. The envisioned deployment model for rLEDBAT is that the clients implement rLEDBAT and this enable rLEDBAT in communications with existent standard TCP senders. In particular, the sender MUST implement [I-D.ietf-tcpm-rfc793bis] and it also MUST implement the Time Stamp Option as defined in [RFC7323]. Also, the sender SHOULD implement some of the standard congestion control mechanisms, such as Cubic [RFC8312] or New Reno [RFC5681].¶

rLEDBAT does not defines a new congestion control algorithm. The LBE congestion control algorithm executed in the rLEDBAT receiver is defined in other documents. The rLEDBAT receiver MUST use an LBE congestion control algorithm. Because rLEDBAT assumes a standard TCP sender, the sender will be using a "best effort" congestion control algorithm (such as Cubic or New Reno). Since rLEDBAT uses the Receive Window to control the sender's rate and the sender calculates the sender's window as the minimum of the Receive window and the congestion window, rLEDBAT will only be effective as long as the congestion control algorithm executed in the receiver yields a smaller window than the one calculated by the sender. This is normally the case when the receiver is using an LBE congestion control algorithm. The rLEDBAT receiver SHOULD use the LEDBAT congestion control algorithm [RFC6817] or the LEDBAT++ congestion control algorithm [I-D.irtf-iccrg-ledbat-plus-plus]. The rLEDBAT MAY use other LBE congestion control algorithms defined elsewhere. Irrespectively of which congestion control algorithm is executed in the receiver, an rLEDBAT connection will never be more aggressive than standard TCP since it is always bounded by the congestion control algorithm executed at the sender.¶

rLEDBAT is essentially composed of three types of mechanisms, namely, those that provide the means to measure the packet delay (either the round trip time or the one way delay, depending on the selected algorithm), mechanisms to detect packet loss and the means to manipulate the Receive Window to control the sender's rate. The former provide input to the LBE congestion control algorithm while the latter uses the congestion window computed by the LBE congestion control algorithm to manipulate the Receive window, as depicted in the figure.¶

+------------------------------------------+
|   TCP receiver                           |
|                      +-----------------+ |
|                      |  +------------+ | |
|   +---------------------|     RTT    | | |
|   |                  |  | Estimation | | |
|   |                  |  +------------+ | |
|   |                  |                 | |
|   |                  |  +------------+ | |
|   |      +--------------| Loss, RTX  | | |
|   |      |           |  | Detection  | | |
|   |      |           |  +------------+ | |
|   v      v           |                 | |
| +----------------+   |                 | |
| | LBE Congestion |   |    rLEDBAT      | |
| |    Control     |   |                 | |
| +----------------+   |                 | |
|       |              |  +------------+ | |
|       |              |  | RCV-WND    | | |
|       +---------------->| Control    | | |
|                      |  +------------+ | |
|                      +-----------------+ |
+------------------------------------------+

We describe each of the rLEDBAT components next.¶

4. Experiment Considerations

The status of this document is Experimental. The general purpose of the proposed experiment is to gain more experience running rLEDBAT over different network paths to see if the constants work well in all cases. Specifically, we would like to learn about the following aspects of the rLEDBAT mechanism:¶

• - Interaction between the sender and the receiver Congestion control algorithms. rLEDBAT posits that because the rLEDBAT receiver is using a less-than-best-effort congestion control algorithm, the receiver congestion control algorithm will expose a smaller congestion window (conveyed though the Receive Window) than the one resulting from the congestion control algorithm executed at the sender. One of the purposes of the experiment is learn how these two interact and if the assumption that the receiver side is always controlling the sender's rate (and making rLEDBAT effective) holds. The experiment should include the different congestion control algorithms that are currently widely used in the Internet, including Cubic, BBR and LEDBAT(++).¶

• - Interaction between rLEDBAT and Active Queue Management techniques such as Codel, PIE and L4S.¶

5. Security Considerations

Overall, we believe that rLEDBAT does not introduce any new vulnerabilities to existing TCP endpoints, as it relies in existing TCP knobs, notably the Receive Window and Timestamps.¶

Specifically, rLEDBAT uses RCV WND to modulate the rate of the sender. An attacker wishing to starve a flow can simply reduce the RCV WND, irrespectively whether rLEDBAT is being used or not.¶

We can further ask ourselves whether the attacker can use the rLEDBAT mechanisms in place to force the rLEDBAT receiver to reduce the RCV WND. There are two ways an attacker can do that. One would be to introduce an artificial delay to the packets either by actually delaying the packets or modifying the Timestamps. This would cause the rLEDBAT to believe that a queue is building up and reduce the RCV WND. Note that an attacker to do that must be on path, so if that is the case, it is probably more direct to simply reduce the RCV WND.¶

The other option would be for the attacker to make believe the rLEDBAT receiver that a loss has occur. To do that, it basically needs to retransmit an old packet (to be precise, it needs to transmit a packet with the right sequence number and the right port and IP numbers). This means that the attacker can achieve a reduction of incoming flows to the rLEDBAT receiver not only by modifying the RCV WND field of the packets originated from the rLEDBAT host, but also by injecting packets with the proper sequence number in the other direction. This may slightly expand the attack surface.¶

6. IANA Considerations

No actions are required from IANA.¶

7. Acknowledgements

This work was supported by the EU through the StandICT CCI project, the StandICT CEL6 project, the NGI Pointer RIM project and the H2020 5G-RANGE project and by the Spanish Ministry of Economy and Competitiveness through the 5G-City project (TEC2016-76795-C6-3-R).¶

We would like to thank ICCRG chairs Reese Enghardt and Vidhi Goel for their support on this work. We would also like to thank Daniel Havey for his help.¶

8. Informative References

[Apple]

Stuart, S.C. and V.G. Vidhi, "Reduce network delays for your app", , WWDC21 https://developer.apple.com/videos/play/wwdc2021/10239/, 2021.

[COMNET1]

Bagnulo, M.B. and A.G. Garcia-Martinez, "An experimental evaluation of LEDBAT++", , Computer Networks Volume 212, 2022.

[COMNET2]

Bagnulo, M.B. and A.G. Garcia-Martinez, "When less is more: BBR versus LEDBAT++", , Computer Networks Volume 219, 2022.

[COMNET3]

Bagnulo, M.B., Garcia-Martinez, A.G., Mandalari, A.M., Balasubramanian, P.B,., Havey, D.H., and G.M. Montenegro, "Design, implementation and validation of a receiver-driven less-than-best-effort transport", , Computer Networks Volume 233, 2022.

[I-D.ietf-tcpm-rfc793bis]

Eddy, W., "Transmission Control Protocol (TCP)", Work in Progress, Internet-Draft, draft-ietf-tcpm-rfc793bis-28, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-28>.

[I-D.irtf-iccrg-ledbat-plus-plus]

Balasubramanian, P., Ertugay, O., and D. Havey, "LEDBAT++: Congestion Control for Background Traffic", Work in Progress, Internet-Draft, draft-irtf-iccrg-ledbat-plus-plus-01, 25 August 2020, <https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-ledbat-plus-plus-01>.

[RFC5681]

Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.

[RFC6817]

Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.

[RFC7323]

Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.

[RFC8312]

Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", RFC 8312, DOI 10.17487/RFC8312, February 2018, <https://www.rfc-editor.org/info/rfc8312>.

[Windows11]

Forsmann, C.F., "What's new in Delivery Optimization", , Microsoft Documentation https://learn.microsoft.com/en-us/windows/deployment/do/whats-new-do, 2023.

[WindowsServer]

Havey, D.H., "LEDBAT Background Data Transfer for Windows", , Microsoft Blog https://techcommunity.microsoft.com/t5/networking-blog/ledbat-background-data-transfer-for-windows/ba-p/3639278, 2022.

Appendix A. rLEDBAT pseudo-code

We next describe how to integrate the proposed rLEDBAT mechanisms and an LBE delay-based congestion control algorithm such as LEDBAT or LEDBAT++. We describe the integrated algorithm as two procedures, one that is executed when a packet is received by a rLEDBAT-enabled endpoint, Figure 2 and another, Figure 3, that is executed when the rLEDBAT-enabled endpoint sends a packet. At the beginning, rlwnd is set to its maximum value, so that the sending rate of the sender is governed by the flow control algorithm of the receiver and the TCP slow start mechanism of the sender, and the ackedBytes variable is set to 0.¶

We assume that the LBE congestion control algorithm defines a WindowIncrease() function and a WindowDecrease() function. For example, in the case of LEDBAT++, the WindowIncrease() function is an additive decrease, while the WindowDecrease() function is a multiplicative decrease. In the case of the WindowIncrease(), we assume that it takes as input the current window size and the the number of bytes that were acknowledged since the last window update (ackedBytes) and returns as output the updated window size. In the case of WindowDecrease(), it takes as input the current window size and returns the updated window size.¶

The data structures used in the algorithms are as follows. The sentList is a list that contains the TSval and the local send time of each packet sent by the rLEDBAT-enabled endpoint. The TSecr field of the packets received by the rLEDBAT-enabled endpoint are matched with the sendList to compute the RTT.¶

The RTT values computed for each received packet are stored in the RTTlist, which contains also the received TSecr (to avoid using multiple packets with the same TSecr for RTT calculations, only the first packet received for a given TSecr is used to compute the RTT). It also contains the local time at which the packet was received, to allow selecting the RTTs measured in a given period (e.g., in the last 10 minutes). RTTlist is initialized with all its values to its maximum.¶

procedure RECEIVEPACKET
  \\Looks for first sent packet with same TSval as TSecr, and,
  \\returns time difference
  receivedRTT =computeRTT(sentList,receivedTSecr,receivedTime)

  \\Inserts minimum value for a given receivedTSecr
  \\note that many received packets may contain same receivedTSecr
  insertRTT (RTTlist, receivedRTT, receivedTSecr, receivedTime)

  filteredRTT = minLastKMeasures(RTTlist,K =4)
  baseRTT = minLastNSeconds(RTTlist,N = 180)
  qd = filteredRTT-baseRTT

  \\ackedBytes is the number of bytes that can be used to reduce
  \\the Receive Window - without shrinking it- if necessary
  ackedBytes = ackedBytes + receiveBytes

  if retransmittedPacketDetected then
        rlwnd = DecreaseWindow(rlwnd) \\ Only once per RTT
  end if
  if qd < T then
        rlwnd = IncreaseWindow(rlwnd, ackedBytes)
  else
        rlwnd = DecreaseWindow(rlwnd)
  end if
end procedure

procedure SENDPACKET
  if (rlwnd > rlwndPrevious) or (rlwnd-rlwndPrevious < ackedBytes)
  then
        rlwndPrevious = rlwnd
  else
        rlwndPrevious = rlwnd-ackedBytes
  end if
  ackedBytes = 0
  rlwndPrevious = rlwnd

  \\Compute the RWND to include in the packet
  rlwnd = min(rlwnd, fcwnd )
end procedure