LEDBAT

Low Extra Delay Background Transport (LEDBAT) is a way to transfer data on the Internet quickly without clogging the network. LEDBAT was invented by Stanislav Shalunov and is used by Apple for software updates, by BitTorrent for most of its transfersThis Is How Your BitTorrent Downloads Move So Fast
July 29, 2013, Retrieved November 24, 2013 and by Microsoft SCCM software distribution points. At one point in time, LEDBAT was estimated to carry 13–20% of Internet traffic. LEDBAT is a delay-based congestion control algorithm that uses all the available bandwidth while limiting the increase in delay; it does so by measuring one-way delay and using changes in the measurements to limit congestion that the LEDBAT flow itself induces in the network. LEDBAT is described in RFC 6817.

Design goals

LEDBAT congestion control has the following goals:
# Use all available bandwidth, and to maintain a low queueing delay when no other traffic is present,
# Limit the queuing delay it adds to that induced by other traffic, and
# To yield quickly to standard TCP that share the same bottleneck link.

Implementations and deployment

The two main implementations are uTP by BitTorrent and as part of TCP by Apple. BitTorrent uses uTP for most traffic and makes the code available under an open-source license. Apple uses LEDBAT for Software Updates so that large software downloads to macOS computers and iOS devices do not interfere with normal user activities; Apple also makes the source code available.

Both of the above implementations aim to limit the network queuing delay to 100ms. This is the maximum allowed for by the standardized protocol. If one used a lower value, then it would be starved when the other was in use.

Windows 10 Anniversary Update introduced support for LEDBAT via undocumented socket option as an experimental Windows TCP Congestion Control Module and Windows Server 2019.

Example

Assumptions:
# The clocks of the sender and the receiver are not synchronized.
# The sender sends at a fixed rate.

The sender sends 5 packets of data every 10 clock counts: 10, 20, 30, 40, 50. The units are unimportant. The receiver is receiving data not only from this particular sender but also from other sources. For the 5 packets that were sent, the receiver receives them at the following clock counts: 112, 135, 176, 250, 326. The first differences (one way delay) between the received and sent clock counts are: 102, 115, 146, 210, 276. The second differences (change in one way delay) are: 13 (115 - 102), 31, 64 and 66. The receiver will infer from the positive increase in one way delays that congestion is increasing and adjust the transfer rate accordingly.

See also

* TCP congestion control

References

{{reflist

Network protocols