RFC 6297

A Survey of Lower-than-Best-Effort Transport Protocols

📅 published June 2011, from ietf

RFC 6297: A Survey of Lower-than-Best-Effort Transport Protocols 🎀

RFC number: 6297 Title: A Survey of Lower-than-Best-Effort Transport Protocols Authors: M. Welzl (University of Oslo) and D. Ros (IT / Telecom Bretagne) Category: Informational ISSN: 2070-1721 Date: June 2011

Abstract ✨

okay so this doc is a survey of transport protocols that are built to have a smaller bandwidth and/or delay impact on standard TCP than standard TCP itself has when they share a bottleneck with it 💅 these protocols could be used for delay-insensitive "background" traffic, because they give you what people call a "less than" (or "lower than") best-effort service 🦋

Status of This Memo 🌸

this document is not an Internet Standards Track specification 🙈 it's published for informational purposes

this doc is a product of the Internet Engineering Task Force (IETF) 🌈 it represents the consensus of the IETF community and got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑 not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🧚

if you want the current status, any errata, or a way to give feedback, go to http://www.rfc-editor.org/info/rfc6297 💖

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication 📜 please read these carefully, because they explain your rights and restrictions for this doc ✨ any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅

Table of Contents 🍓

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  2.  Delay-Based Transport Protocols  . . . . . . . . . . . . . .  3
    2.1.  Accuracy of Delay-Based Congestion Predictors  . . . . . .  6
    2.2.  Potential Issues with Delay-Based Congestion Control
          for LBE Transport  . . . . . . . . . . . . . . . . . . . .  7
  3.  Non-Delay-Based Transport Protocols  . . . . . . . . . . . . .  8
  4.  Upper-Layer Approaches . . . . . . . . . . . . . . . . . . . .  8
    4.1.  Receiver-Oriented, Flow-Control-Based Approaches . . . . .  9
  5.  Network-Assisted Approaches  . . . . . . . . . . . . . . . . . 10
  6.  LEDBAT Considerations  . . . . . . . . . . . . . . . . . . . . 12
  7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
  8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
  9.  Informative References . . . . . . . . . . . . . . . . . . . . 12

1. Introduction 🦋

okay bestie, this doc gives a quick tour of ideas for getting a Less-than-Best-Effort (LBE) service using end-host mechanisms 💖 we loosely define an LBE service as one that has a smaller bandwidth and/or delay impact on standard TCP than standard TCP has itself, when it shares a bottleneck with it ✨ systems built to give you this service are called LBE systems 🌸

the one exception is TCP Vegas, which we include for historical reasons 🎀 we leave out systems that have been seen acting like LBE under some circumstances but weren't designed for it, like RAPID [Kon09] 🙈 that's not the vibe we're going for

generally, LBE behavior comes from reacting to queue growth earlier than standard TCP would, or from changing TCP's congestion-avoidance behavior without using any extra implicit feedback 💅 so this assumes you already know TCP congestion control [RFC5681] (no cap, you need this one) 🧠 some mechanisms get LBE behavior without changing transport-protocol standards, like by changing the receiver window of standard TCP 🌈 others use network-level mechanisms at the transport layer for LBE purposes 👑

we sort the solutions into four buckets: delay-based transport protocols, non-delay-based transport protocols, upper-layer approaches, and network-assisted approaches 🍓 some of the schemes in the first two buckets could be built on TCP without changing its header format, which would make them easier to deploy on the Internet 🫶 the schemes in the third bucket are, by design, supposed to be especially easy to deploy, because they only describe how existing transport protocols are used 🧚 and finally, mechanisms in the last bucket need changes to equipment along the path, which can seriously complicate deployment 😭

this doc is a product of the Low Extra Delay Background Transport (LEDBAT) working group 💜 it aims to put the congestion control algorithm that the working group specified [Sha11] into the context of the state of the art in LBE transport ✨ this survey is not exhaustive (that wouldn't be possible or useful, bestie) 💅 the authors picked key, well-known, or otherwise interesting techniques at their own discretion 🌈

there's also a bunch of related work that's about the LBE concept but doesn't offer a solution you can install in end-hosts or expect to work over the Internet 🙈 for example, there's a Diffserv-based, Lower-Effort service [RFC3662], and the IETF Congestion Exposure (CONEX) working group is building a mechanism that could incentivize LEDBAT-like applications 🦋 that stuff is outside the scope of this document, so we're not going there today 💖

2. Delay-Based Transport Protocols ✨

okay bestie, it's actually wrong to assume that "little impact on standard TCP" automatically means "small sending rate" 🙅‍♀️. Without Explicit Congestion Notification (ECN) support, standard TCP will normally keep increasing its congestion window (and effective sending rate) until a queue overflows. That causes one or more packets to get dropped, and then the effective rate drops too. A protocol that stops ramping up before that happens can, in principle, get better performance than standard TCP. it's giving smart, not slow 🧠💅

TCP Vegas [Bra94] is one of the first protocols known to have a smaller sending rate than standard TCP when both share a bottleneck [Kur00] 🦋. And the wild part? It was designed to get more throughput, not less! When TCP Vegas is the only congestion control algorithm on the bottleneck, its throughput is actually greater than standard TCP's. Depending on the bottleneck queue length, though, TCP Vegas can get starved by standard TCP flows 😭. This can be fixed to some degree by the Random Early Detection (RED) Active Queue Management mechanism [RFC2309]. Vegas moves its sending rate up or down in a linear way, based on the difference between the expected throughput and the actual throughput. That estimate is built from RTT measurements 📏.

The congestion-avoidance behavior is Vegas's most important feature, both historically and for this document 👑. (It's been shown that other parts of the protocol can sometimes matter more for its overall behavior [Hen00], so no cap, it's not the whole story.) In congestion avoidance, once per RTT, TCP Vegas works out the expected throughput as WindowSize / BaseRTT, where WindowSize is the current congestion window and BaseRTT is the minimum of all measured RTTs. Then it compares that with the actual throughput, which is measured from recent acknowledgements. If the actual throughput is smaller than the expected throughput minus a threshold called "beta", that's a sign of congestion, so the protocol linearly decreases its rate 📉. If the actual throughput is greater than the expected throughput minus a threshold called "alpha" (with alpha < beta), that's a sign the network is underutilized, so the protocol linearly increases its rate 📈.

TCP Vegas has been analyzed extensively, and one of its most iconic properties is its fairness between multiple flows of the same kind 🌈. It doesn't penalize flows with large propagation delays the way standard TCP does. It also wasn't the first protocol to use delay as a congestion indication. Its predecessors (like CARD [Jai89], Tri-S [Wan91], or DUAL [Wan92]) aren't discussed here, but only because TCP Vegas took the historical "landmark" role in the literature 🏆.

Delay-based transport protocols that were designed to be non-intrusive include TCP Nice [Ven02] and TCP Low Priority (TCP-LP) [Kuz06] 🧚. TCP Nice [Ven02] uses the same basic approach as TCP Vegas but improves on it in some ways. Because of its moderate linear-decrease congestion response, TCP Vegas can affect standard TCP even though it detects congestion early. TCP Nice fixes this by halving the congestion window (at most once per RTT, like standard TCP) instead of reducing it linearly 💖. To avoid being too conservative, this only happens if a fixed predefined fraction of delay-based incipient congestion signals shows up within one RTT. Otherwise, TCP Nice falls back to the congestion-avoidance rules of TCP Vegas if no packet was lost, or to standard TCP if one was. Another feature of TCP Nice is that it can support a congestion window of less than one packet, by clocking out single packets over more than one RTT 🤯. With ns-2 simulations and real-life experiments using a Linux implementation, the authors of [Ven02] show that TCP Nice achieves its goal: it uses spare capacity efficiently while staying non-intrusive to standard TCP 🫶.

Next up is TCP-LP [Kuz06] 🎀. Other than TCP Vegas and TCP Nice, it uses only the one-way delay (OWD) instead of the RTT as an indicator of incipient congestion. That's to avoid reacting to delay fluctuations caused by reverse cross-traffic. Using the TCP Timestamps option [RFC1323], the OWD is determined as the difference between the receiver's Timestamp value in the ACK and the original Timestamp value that the receiver copied into the ACK. The result of this subtraction can only precisely represent the OWD if clocks are synchronized, but its absolute value doesn't matter to TCP-LP, so clock synchronization isn't needed 🙌. Using a constant smoothing parameter, TCP-LP calculates an Exponentially Weighted Moving Average (EWMA) of the measured OWD. It then checks whether the result exceeds a threshold within the range of the minimum and maximum OWD seen during the connection's lifetime. If it does, that counts as an "early congestion indication". The minimum and maximum OWD values are initialized during the slow-start phase 🌸.

Now, how TCP-LP reacts to an early congestion indication is so clever 🧠✨. It tries to strike a middle ground between two extremes. One is the overly conservative choice of immediately setting the congestion window to one packet. The other is the presumably too aggressive choice of just halving the congestion window like standard TCP. TCP-LP delays the first option by an extra RTT, to see if there's persistent congestion or not. It halves the window at first in response to an early congestion indication, then initializes an "inference time-out timer" and keeps the current congestion window until that timer fires. If another early congestion indication shows up during this "inference phase", the window gets set to 1. Otherwise, the window is maintained, and TCP-LP keeps increasing it in the standard Additive-Increase fashion. This means it takes at least two RTTs for a TCP-LP flow to decrease its window to 1, and that, like standard TCP, TCP-LP reacts to congestion at most once per RTT 🎯.

The authors of TCP-LP [Kuz06] use a simple analytical model to show that a delay-based LBE transport is feasible 🦋. Because the relationship between throughput and RTT is non-linear, it's possible to avoid interfering with standard TCP traffic even when the flows in question have a larger RTT than standard TCP flows. With ns-2 simulations and real-life experiments using a Linux implementation, the authors of [Kuz06] show that TCP-LP is largely non-intrusive to TCP traffic. At the same time, it can use a large portion of the excess network bandwidth, which is fairly shared among competing TCP-LP flows. They also show that using their protocol for bulk data transfers greatly reduces file transfer times for competing best-effort web traffic 🚀.

Sync-TCP [Wei05] follows a similar approach to TCP-LP, adapting its reaction to congestion based on changes in the OWD 💜. It compares the estimated (average) forward queuing delay to the maximum observed delay. Then it adapts the Additive-Increase Multiplicative-Decrease (AIMD) parameters depending on the trend the average delay follows over an observation window. The authors of [Wei05] didn't explicitly consider using it as an LBE protocol, but Sync-TCP was designed to react early to incipient congestion while grabbing available bandwidth more aggressively than a standard TCP in congestion-avoidance mode 💅.

Delay-based congestion control is also the basis of proposals that aim to adapt TCP's congestion avoidance to very high-speed networks 🏎️💨. Some of these, like Compound TCP [Tan06] [Sri08] and TCP Illinois [Liu08], are hybrid loss- and delay-based mechanisms. Others (e.g., NewVegas [Dev03], FAST TCP [Wei06], or CODE TCP [Cha10]) are variants of Vegas that are based primarily on delays 🍓.

2.1. Accuracy of Delay-Based Congestion Predictors

The accuracy of delay-based congestion predictors has been the subject of a lot of research, see, e.g., [Bia03], [Mar03], [Pra04], [Rew06], [McC08] 📚. The main result of most of these studies is that delays (or, more precisely, round-trip times) are, in general, only weakly correlated with congestion 🙈. There are several factors that may cause such a poor correlation:

  • Bottleneck buffer size: in principle, a delay-based mechanism could be made "more than TCP friendly" if buffers are "large enough", so that RTT fluctuations and/or deviations from the minimum RTT can be detected by the end-host with reasonable accuracy. Otherwise, it may be hard to tell real delay variations apart from measurement noise 🫠.
  • RTT measurement issues: in principle, RTT samples may suffer from poor resolution, because timers are too coarse-grained for the scale of delay fluctuations. Also, a flow may get a very noisy estimate of RTTs due to undersampling under some circumstances (e.g., when the flow rate is much lower than the link bandwidth). For TCP, other potential sources of measurement noise include TCP segmentation offloading (TSO) and the use of delayed ACKs [Hay10]. A congested reverse path may also lead to an erroneous assessment of the congestion state of the forward path. Finally, on fast or short-distance links, most of the measured delay can actually be due to processing in the hosts involved. That processing delay usually isn't of interest, and it can cause fluctuations that have nothing to do with the network at all 🤷‍♀️.
  • Level of statistical multiplexing and RTT sampling: it may be easy for an individual flow to "miss" loss/queue overflow events, especially if the number of flows sharing a bottleneck buffer is significant. This is nicely illustrated, e.g., in Figure 1 of [McC08] 📊.
  • Impact of wireless links: several mechanisms typical of wireless links, like link-layer scheduling and error recovery, may induce strong delay fluctuations over short timescales [Gur04] 📡.

Interestingly, the results of Bhandarkar et al. [Bha07] seem to paint a slightly different picture about how accurate delay-based congestion prediction is 🤔. Bhandarkar et al. claim it's possible to significantly improve prediction accuracy by adopting some simple techniques (smoothing of RTT samples, and increasing the RTT sampling frequency). Still, they acknowledge that even with those techniques, detection errors can't be eradicated. Their proposed delay-based congestion-avoidance method, PERT (Probabilistic Early Response TCP), reduces the impact of residual detection errors by using a probabilistic response mechanism to congestion-detection events 🌈✨.

2.2. Potential Issues with Delay-Based Congestion Control for LBE Transport 🎀

okay so bestie, whether a delay-based protocol actually behaves the way it's supposed to (like, it's "more than TCP friendly," or it grabs bandwidth super aggressively 💀) can depend on those accuracy issues from Section 2.1. 😭 And protocols like Vegas have to keep an estimate of the minimum ("base") delay, which makes them highly sensitive to route changes that happen during the flow's lifetime [Mo99]. the way that's giving fragile 🥺

Now, false positives and false negatives with a delay-based congestion detector. Most studies focus on the throughput loss from wrongly detecting queue build-up or wrongly detecting that congestion has cleared. ngl, for an LBE transport protocol it's arguably better to err on the "more-than-TCP-friendly" side, meaning always yield to perceived congestion whether it's "real" or not 🫶 BUT if it fails to detect congestion (because of one of those accuracy problems), it acts not LBE, and that's a major vibe shift 🙈 For example, picture a bottleneck buffer that's small, so queueing delay at the bottleneck barely adds to the global end-to-end delay. In that case, a delay-based flow could end up hogging a good chunk of bandwidth compared to a competing standard TCP flow, unless it also has a suitable reaction to loss. 👑

Delay-based mechanisms can also suffer from the so-called "latecomer advantage" (or "latecomer unfairness") problem 😤 Imagine the bottleneck link is already (very) congested. Then delay variations are pretty tiny, so it's really hard to tell an empty queue from a heavily-loaded one based on delay fluctuation 💅 That means a newly-arriving delay-based flow might start sending faster right when things are already packed, and eventually it drives away loss-based flows [Sha05] [Car10]. not fair at all, periodt 💜

3. Non-Delay-Based Transport Protocols 🦋

there are a few transport-layer proposals that get an LBE service without using delay as their congestion signal ✨ In the algorithms below, the flow's loss rate determines the sending rate, either implicitly or explicitly. The sending rate gets adapted so the flow takes a smaller share of the available bandwidth than standard TCP would. These mechanisms likely cause more queuing delay and react to congestion more slowly than the delay-based ones 🐢

4CP [Liu07], short for "Competitive and Considerate Congestion Control," gives an LBE service by changing the window control rules of standard TCP 🌸 It keeps a "virtual window" that, during a so-called "bad congestion phase," gets pushed below a predefined minimum value of the actual congestion window. The congestion window only grows again once the virtual window goes back above that minimum. So the virtual window basically controls how long the sender transmits at a fixed minimum rate, which is lowkey genius 🧠 Whether the congestion state counts as "bad" or "good" depends on whether the loss event rate is above or below a threshold (or target) value. The 4CP congestion-avoidance algorithm lets you set a target average window, avoids starving "background" flows, and bounds the impact on "foreground" flows 🫧 Its performance was checked in ns-2 simulations and in real-life experiments with a kernel-level implementation in Microsoft Windows Vista.

MulTFRC [Dam09] is an extension of TCP-Friendly Rate Control (TFRC) [RFC5348] for multiple flows 🍓 It takes the main idea of MulTCP [Cro98] and similar proposals (e.g., [Hac04], [Hac08], [Kuo08]) and pushes it a step further. A single MulTCP flow tries to emulate (and be as friendly as) a number N > 1 of parallel TCP flows. By supporting values of N between 0 and 1, MulTFRC can work as a mechanism for an LBE service 🧚 Since it doesn't react to delay like the protocols in Section 2, but adjusts its rate like TFRC, MulTFRC can probably be expected to be more aggressive than mechanisms like TCP Nice or TCP-LP. This also means MulTFRC is less likely to be prone to starvation, because its aggressiveness is tunable at a fine granularity, even when N is between 0 and 1 ⭐

4. Upper-Layer Approaches 🌈

The proposals in this section don't require modifying transport-protocol standards 🫶 Most of them can be regarded as running "on top" of an existing transport. They may be implemented either at the application layer (i.e., in user-level processes) or in the kernel of the end-hosts' operating systems.

"Upper-layer" mechanisms may arguably be easier to deploy than transport-layer approaches, since they don't require any changes to the transport itself 💖

A simplistic, application-level approach to a background transport service is scheduling automated transfers for times when the network is lightly loaded, as described in [Dyk02] for cooperative proxy caching 🌙 The catch is that this might not work for applications like peer-to-peer file transfer, since "off-peak hour" doesn't really mean anything when end-hosts can be located anywhere in the world 🌍

The so-called Background Intelligent Transfer Service [BITS] is implemented in several versions of Microsoft Windows. BITS uses a system of application-layer priority levels for file-transfer jobs, plus monitoring of the bandwidth usage of the network interface (or, in more recent versions, of the network gateway connected to the end-host). That way, low-priority transfers at a given end-host give way to both high-priority (foreground) transfers and traffic from interactive applications on the same host 🪄

A different approach is taken in [Egg05]. Here, the priority of a flow is reduced via a generic idletime scheduling strategy in a host's operating system 🧊 The results in that paper show the new scheduler can effectively shield regular tasks from low-priority ones (e.g., TCP from greedy UDP) with only a minor performance impact. BUT it's an underlying assumption that all involved end-hosts would use the idletime scheduler. In other words, the focus of that work is not protecting a standard TCP flow that originates from any host where the scheduling scheme isn't implemented 😬

4.1. Receiver-Oriented, Flow-Control-Based Approaches 🎧

Some proposals get an LBE behavior by exploiting existing transport-layer features, typically on the "receiving" side 👂 In particular, TCP's built-in flow control can be used as a means to achieve a low-priority transport service ✨

The mechanism described in [Spr00] is an example of this technique. It controls bandwidth by letting the receiver intelligently manipulate the receiver window of standard TCP. That works because the authors assume a client-server setting where the receiver's access link is typically the bottleneck 🫠 The scheme includes a delay-based calculation of the expected queue length at the bottleneck, which is pretty similar to the calculation in the delay-based protocols above, e.g., TCP Vegas. Using a Linux implementation, where TCP flows are classified according to their application's needs, Spring et al. show in [Spr00] that a significant improvement in packet latency can be attained over an unmodified system, while maintaining good link utilization 🔥

A similar method is employed by Mehra et al. [Meh03], where both the advertised receiver window and the delay in sending ACK messages are dynamically adapted to attain a given rate 💫 As in [Spr00], Mehra et al. assume the bottleneck is located at the receiver's access link. However, they also propose a bandwidth-sharing system, which allows control of the bandwidth allocated to different flows, as well as allotment of a minimum rate to some flows 🎀

Receiver window tuning also shows up in [Key04], where choosing the right window value is phrased as an optimization problem 🧮 Two algorithms are presented: binary search (which is faster than the other one at reaching a good operating point, but fluctuates) and stochastic optimization (which doesn't fluctuate, but converges more slowly than binary search). These algorithms only use the previous receiver window and the amount of data received during the previous control interval as input. According to [Key04], the encouraging simulation results suggest such an application-level mechanism can work almost as well as a transport-layer scheme like TCP-LP 🥹

Another way of dealing with non-interactive flows, like web prefetching, is to rate-limit the transfer of that bursty traffic [Cro98b] 🛼 Note that one of the techniques used in [Cro98b] is, precisely, to have the downloading application adapt the TCP receiver window, so the data rate drops to the minimum needed. That way it disturbs other flows as little as possible while still respecting a deadline for transferring the data 🫶

5. Network-Assisted Approaches ✨

okay so this one is about asking the network itself for help 🌐 network-layer stuff like active queue management (AQM) and packet scheduling in routers can be exploited by a transport protocol to get an LBE service 💅 these approaches can improve protection of non-LBE flows (like when scheduling is used) 🛡️ and approaches using an explicit, AQM-based congestion signaling may arguably be more robust than, say, delay-based transports at spotting impending congestion 🔥 the obvious catch tho: any network-assisted approach needs modifications in both end-hosts and intermediate network nodes 🙈

Harp [Kok04] gives you an LBE service by pushing background traffic over less-utilized paths, using multipath routing and multipath congestion control 🦋 the sneaky part is it doesn't need every router changed, because it uses edge nodes as relays 🧚 according to the authors, those edge nodes should be gateways of organizations so the scheme lines up with usage incentives, but the technical solution would also work if Harp was only deployed in end-hosts 💖 it spots impending congestion by looking at delay, similar to TCP Nice [Ven02] ✨ and it manages to improve the utilization and fairness of TCP over pure single-path solutions WITHOUT changing TCP itself 😭👑

another technique is the one used by protocols like Network-Friendly TCP (NF-TCP) [Aru10] 🌸 a bandwidth-estimation module built into the transport protocol lets it rapidly take advantage of free capacity 🏃‍♀️ NF-TCP pairs this with early congestion detection based on Explicit Congestion Notification (ECN) [RFC3168] and RED [RFC2309] 💜 when congestion starts building up, tuning a RED queue lets low-priority (i.e., NF-TCP) packets get marked with a much higher probability than high-priority (i.e., standard TCP) packets, so the low-priority flows yield bandwidth before standard TCP flows do 🥹 NF-TCP could be implemented by adapting the congestion control behavior of TCP without needing to change the protocol on the wire -- the only exception is that NF-TCP-capable routers must be able to somehow distinguish NF-TCP traffic from other TCP traffic 🫶

In [Ven08], Venkataraman et al. propose a transport-layer approach that leverages an existing, network-layer LBE service based on priority queueing 🎀 their transport protocol, which they call PLT (Priority-Layer Transport), splits a layer-4 connection into two flows: a high-priority one and a low-priority one 🍓 the high-priority flow goes over the higher-priority queueing class (in principle, offering a best-effort service) using an AIMD, TCP-like congestion control mechanism 💅 the low-priority flow, mapped to the LBE class, uses a non TCP-friendly congestion control algorithm 😈 so the goal of PLT is to maximize its aggregate throughput by grabbing unused capacity in an aggressive way, while still protecting standard TCP flows carried by the best-effort class 👑 similar in spirit, [Ott03] proposes simple changes to only the AIMD parameters of TCP for use over a network-layer LBE service, so that such "filler" traffic can aggressively eat unused bandwidth 🍽️✨

also, [Ven08] considers a way to detect the lack of priority queueing in the network, so the non-TCP friendly flow can be inhibited 🕵️‍♀️ the PLT receiver monitors the loss rate of both flows 👀 if the high-priority flow starts seeing losses while the low-priority one does not experience 100% loss, that's taken as an indication of the absence of strict priority queueing 💀 wild, right?

6. LEDBAT Considerations 🎧

okay, the previous sections proved there's a LOT of work on getting an LBE service, and it's super heterogeneous 🌈 the algorithm developed by the LEDBAT working group [Sha11] can be classified as a delay-based mechanism, so it's giving "similar in spirit" to the protocols in Section 2 🦋 BUT it's not a protocol 🙃 how it actually gets applied to the Internet (how to use existing or even new transport protocols together with the LEDBAT algorithm) is NOT defined by the LEDBAT working group 😭 since it heavily relies on delay, the discussion in Sections 2.1 and 2.2 applies to it 💅 LEDBAT's performance has been analyzed against some of the other work covered here in several articles, e.g. [Aru10], [Car10], [Sch10] 📚 but those analyses have to be examined with care, bestie, because at the time of writing LEDBAT was still a moving target 🎯

7. Acknowledgements 🫶

the authors would like to thank Melissa Chavez, Dragana Damjanovic, and Yinxia Zhao for reference pointers 🙏 and also Jari Arkko, Mayutan Arumaithurai, Elwyn Davies, Wesley Eddy, Stephen Farrell, Mirja Kuehlewind, Tina Tsou, and Rolf Winter for their detailed reviews and suggestions 💖✨

8. Security Considerations 🔐

⚠️ okay this part is short but it's a whole vibe: this document introduces no new security considerations. 💀 the security story of this document is literally a blank page, so don't go looking for hidden threats here 😤

9. Informative References ✨

okay bestie, here are the receipts! 📚 every paper and doc the spec leans on, listed right here 💅

  • [Aru10] Arumaithurai, M., Fu, X., and K. Ramakrishnan, "NF-TCP: A Network Friendly TCP Variant for Background Delay-Insensitive Applications", Technical Report No. IFI-TB-2010-05, Institute of Computer Science, University of Goettingen, Germany, September 2010, <http://www.net.informatik.uni-goettingen.de/publications/1718/NF-TCP-techreport.pdf>.
  • [BITS] Microsoft, "Windows Background Intelligent Transfer Service", <http://msdn.microsoft.com/library/bb968799(VS.85).aspx>.
  • [Bha07] Bhandarkar, S., Reddy, A., Zhang, Y., and D. Loguinov, "Emulating AQM from end hosts", Proceedings of ACM SIGCOMM 2007, 2007.
  • [Bia03] Biaz, S. and N. Vaidya, "Is the round-trip time correlated with the number of packets in flight?", Proceedings of the 3rd ACM SIGCOMM conference on Internet measurement (IMC '03), pages 273-278, 2003.
  • [Bra94] Brakmo, L., O'Malley, S., and L. Peterson, "TCP Vegas: New techniques for congestion detection and avoidance", Proceedings of SIGCOMM '94, pages 24-35, August 1994.
  • [Car10] Carofiglio, G., Muscariello, L., Rossi, D., and S. Valenti, "The quest for LEDBAT fairness", Proceedings of IEEE GLOBECOM 2010, December 2010.
  • [Cha10] Chan, Y., Lin, C., Chan, C., and C. Ho, "CODE TCP: A competitive delay-based TCP", Computer Communications, 33(9):1013-1029, June 2010.
  • [Cro98] Crowcroft, J. and P. Oechslin, "Differentiated end-to-end Internet services using a weighted proportional fair sharing TCP", ACM SIGCOMM Computer Communication Review, vol. 28, no. 3, pp. 53-69, July 1998.
  • [Cro98b] Crovella, M. and P. Barford, "The network effects of prefetching", Proceedings of IEEE INFOCOM 1998, April 1998.
  • [Dam09] Damjanovic, D. and M. Welzl, "MulTFRC: Providing Weighted Fairness for Multimedia Applications (and others too!)", ACM Computer Communication Review, vol. 39, no. 3, July 2009.
  • [Dev03] De Vendictis, A., Baiocchi, A., and M. Bonacci, "Analysis and enhancement of TCP Vegas congestion control in a mixed TCP Vegas and TCP Reno network scenario", Performance Evaluation, 53(3-4):225-253, 2003.
  • [Dyk02] Dykes, S. and K. Robbins, "Limitations and benefits of cooperative proxy caching", IEEE Journal on Selected Areas in Communications, 20(7):1290-1304, September 2002.
  • [Egg05] Eggert, L. and J. Touch, "Idletime Scheduling with Preemption Intervals", Proceedings of 20th ACM Symposium on Operating Systems Principles, SOSP 2005, Brighton, United Kingdom, pp. 249/262, October 2005.
  • [Gur04] Gurtov, A. and S. Floyd, "Modeling wireless links for transport protocols", ACM SIGCOMM Computer Communications Review, 34(2):85-96, April 2004.
  • [Hac04] Hacker, T., Noble, B., and B. Athey, "Improving Throughput and Maintaining Fairness using Parallel TCP", Proceedings of IEEE INFOCOM 2004, March 2004.
  • [Hac08] Hacker, T. and P. Smith, "Stochastic TCP: A Statistical Approach to Congestion Avoidance", Proceedings of PFLDnet 2008, March 2008.
  • [Hay10] Hayes, D., "Timing enhancements to the FreeBSD kernel to support delay and rate based TCP mechanisms", Technical Report 100219A, Centre for Advanced Internet Architectures, Swinburne University of Technology, February 2010.
  • [Hen00] Hengartner, U., Bolliger, J., and T. Gross, "TCP Vegas revisited", Proceedings of IEEE INFOCOM 2000, March 2000.
  • [Jai89] Jain, R., "A delay-based approach for congestion avoidance in interconnected heterogeneous computer networks", ACM Computer Communication Review, 19(5):56-71, October 1989.
  • [Key04] Key, P., Massoulie, L., and B. Wang, "Emulating Low-Priority Transport at the Application Layer: a Background Transfer Service", Proceedings of ACM SIGMETRICS 2004, January 2004.
  • [Kok04] Kokku, R., Bohra, A., Ganguly, S., and A. Venkataramani, "A Multipath Background Network Architecture", Proceedings of IEEE INFOCOM 2007, May 2007.
  • [Kon09] Konda, V. and J. Kaur, "RAPID: Shrinking the Congestion-control Timescale", Proceedings of IEEE INFOCOM 2009, April 2009.
  • [Kuo08] Kuo, F. and X. Fu, "Probe-Aided MulTCP: an aggregate congestion control mechanism", ACM SIGCOMM Computer Communication Review, vol. 38, no. 1, pp. 17-28, January 2008.
  • [Kur00] Kurata, K., Hasegawa, G., and M. Murata, "Fairness Comparisons Between TCP Reno and TCP Vegas for Future Deployment of TCP Vegas", Proceedings of INET 2000, July 2000.
  • [Kuz06] Kuzmanovic, A. and E. Knightly, "TCP-LP: low-priority service via end-point congestion control", IEEE/ACM Transactions on Networking (ToN), Volume 14, Issue 4, pp. 739-752., August 2006, <http://www.ece.rice.edu/networks/TCP-LP/>.
  • [Liu07] Liu, S., Vojnovic, M., and D. Gunawardena, "Competitive and Considerate Congestion Control for Bulk Data Transfers", Proceedings of IWQoS 2007, June 2007.
  • [Liu08] Liu, S., Basar, T., and R. Srikant, "TCP-Illinois: A loss- and delay-based congestion control algorithm for high-speed networks", Performance Evaluation, 65(6-7):417-440, 2008.
  • [Mar03] Martin, J., Nilsson, A., and I. Rhee, "Delay-based congestion avoidance for TCP", IEEE/ACM Transactions on Networking, 11(3):356-369, June 2003.
  • [McC08] McCullagh, G. and D. Leith, "Delay-based congestion control: Sampling and correlation issues revisited", Technical report, Hamilton Institute, 2008.
  • [Meh03] Mehra, P., Zakhor, A., and C. De Vleeschouwer, "Receiver-Driven Bandwidth Sharing for TCP", Proceedings of IEEE INFOCOM 2003, April 2003.
  • [Mo99] Mo, J., La, R., Anantharam, V., and J. Walrand, "Analysis and Comparison of TCP Reno and TCP Vegas", Proceedings of IEEE INFOCOM 1999, March 1999.
  • [Ott03] Ott, B., Warnky, T., and V. Liberatore, "Congestion control for low-priority filler traffic", SPIE QoS 2003 (Quality of Service over Next-Generation Internet), In Proc. SPIE, Vol. 5245, 154, Monterey (CA), USA, July 2003.
  • [Pra04] Prasad, R., Jain, M., and C. Dovrolis, "On the effectiveness of delay-based congestion avoidance", Proceedings of PFLDnet, 2004.
  • [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
  • [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
  • [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
  • [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
  • [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
  • [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
  • [Rew06] Rewaskar, S., Kaur, J., and D. Smith, "Why don't delay-based congestion estimators work in the real-world?", Technical report TR06-001, University of North Carolina at Chapel Hill, Dept. of Computer Science, January 2006.
  • [Sch10] Schneider, J., Wagner, J., Winter, R., and H. Kolbe, "Out of my Way -- Evaluating Low Extra Delay Background Transport in an ADSL Access Network", Proceedings of the 22nd International Teletraffic Congress ITC22, 2010.
  • [Sha05] Shalunov, S., Dunn, L., Gu, Y., Low, S., Rhee, I., Senger, S., Wydrowski, B., and L. Xu, "Design Space for a Bulk Transport Tool", Technical Report, Internet2 Transport Group, May 2005.
  • [Sha11] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", Work in Progress, May 2011.
  • [Spr00] Spring, N., Chesire, M., Berryman, M., Sahasranaman, V., Anderson, T., and B. Bershad, "Receiver based management of low bandwidth access links", Proceedings of IEEE INFOCOM 2000, pp. 245-254, vol. 1, 2000.
  • [Sri08] Sridharan, M., Tan, K., Bansala, D., and D. Thaler, "Compound TCP: A New TCP Congestion Control for High-Speed and Long Distance Networks", Work in Progress, November 2008.
  • [Tan06] Tan, K., Song, J., Zhang, Q., and M. Sridharan, "A Compound TCP approach for high-speed and long distance networks", Proceedings of IEEE INFOCOM 2006, Barcelona, Spain, April 2008.
  • [Ven02] Venkataramani, A., Kokku, R., and M. Dahlin, "TCP Nice: a mechanism for background transfers", Proceedings of OSDI '02, 2002.
  • [Ven08] Venkataraman, V., Francis, P., Kodialam, M., and T. Lakshman, "A priority-layered approach to transport for high bandwidth-delay product networks", Proceedings of ACM CoNEXT, Madrid, December 2008.
  • [Wan91] Wang, Z. and J. Crowcroft, "A new congestion control scheme: slow start and search (Tri-S)", ACM Computer Communication Review, 21(1):56-71, January 1991.
  • [Wan92] Wang, Z. and J. Crowcroft, "Eliminating periodic packet losses in the 4.3-Tahoe BSD TCP congestion control algorithm", ACM Computer Communication Review, 22(2):9-16, January 1992.
  • [Wei05] Weigle, M., Jeffay, K., and F. Smith, "Delay-based early congestion detection and adaptation in TCP: impact on web performance", Computer Communications, 28(8):837-850, May 2005.
  • [Wei06] Wei, D., Jin, C., Low, S., and S. Hegde, "FAST TCP: Motivation, architecture, algorithms, performance", IEEE/ACM Transactions on Networking, 14(6):1246-1259, December 2006.

Authors' Addresses 🎀

the people who wrote this, with their contact info 🦋

Michael Welzl
University of Oslo
Department of Informatics, PO Box 1080 Blindern
N-0316 Oslo
Norway

Phone: +47 22 85 24 20
EMail: michawe@ifi.uio.no


David Ros
Institut Telecom / Telecom Bretagne
Rue de la Chataigneraie, CS 17607
35576 Cesson Sevigne cedex
France

Phone: +33 2 99 12 70 46
EMail: david.ros@telecom-bretagne.eu
📦 where this page comes from