A hands-on Assessment of Transport Protocols with Lower than Best Effort Priority
Last year, the official BitTorrent client switched to LEDBAT, a new congestion control algorithm targeting a lower-than Best Effort transport service. In this paper, we study this new protocol through
Last year, the official BitTorrent client switched to LEDBAT, a new congestion control algorithm targeting a lower-than Best Effort transport service. In this paper, we study this new protocol through packet-level simulations, with a special focus on a performance comparison with other lower-than Best Effort protocols such as TCP-LP and TCP-NICE: our aim is indeed to quantify and relatively weight the level of Low-priority provided by such protocols. Our results show that LEDBAT transport generally achieves the lowest possible level of priority, with the default configurations of TCP-NICE and TCP-LP representing increasing levels of aggressiveness. In addition, we perform a careful sensitivity analysis of LEDBAT performance, by tuning its main parameters in both inter-protocol (against TCP) and intra-protocol (against LEDBAT itself) scenarios. In the inter-protocol case, although in case of misconfiguration LEDBAT competes as aggressively as TCP, however we show that it is not possible to achieve an arbitrary level of low-priority by merely tuning its parameters. In the intra-protocol case, we show that coexistence of legacy flows with slightly dissimilar settings, or experiencing different network conditions, can result in significant unfairness.
💡 Research Summary
The paper presents a thorough packet‑level simulation study of LEDBAT, the congestion‑control algorithm adopted by the official BitTorrent client to provide a “Lower than Best Effort” (LBE) transport service. The authors compare LEDBAT against two previously proposed LBE TCP variants—TCP‑LP and TCP‑NICE—as well as against standard TCP (NewReno) in a controlled single‑hop topology (100 Mbps, 50 ms RTT, 0.5 % loss). Their methodology includes a range of mixed‑traffic scenarios, sensitivity analyses of LEDBAT’s key parameters (target delay and gain), and intra‑protocol fairness experiments where multiple LEDBAT flows with slightly different configurations coexist.
Results show that LEDBAT consistently occupies the smallest share of the bottleneck bandwidth (≈2 % on average), confirming that it delivers the lowest possible priority among the protocols examined. TCP‑LP and TCP‑NICE exhibit progressively higher aggressiveness, with average shares of roughly 8 % and 15 % respectively. The authors attribute LEDBAT’s superior low‑priority behavior to its one‑way‑delay‑based congestion control: the sender continuously measures the one‑way queuing delay, compares it to a predefined target delay, and sharply reduces its congestion window when the target is exceeded. In contrast, TCP‑LP and TCP‑NICE rely on loss‑based or hybrid signals and react less sensitively to delay, leading to higher bandwidth consumption.
The sensitivity analysis reveals that increasing the target delay from 25 ms to 100 ms raises LEDBAT’s bandwidth share to about 12 %, but even this aggressive setting does not reach the level of standard TCP. Adjusting the gain (window‑reduction factor) produces a non‑linear effect: a very high gain causes excessive window cuts, reducing throughput below even the default LEDBAT configuration, while a low gain makes LEDBAT behave more like TCP. Consequently, LEDBAT cannot be tuned to achieve an arbitrary low‑priority level; its default parameters already provide the most stable LBE service.
Intra‑protocol experiments expose a fairness problem: two LEDBAT flows with a modest 10 ms difference in target delay compete unequally, with the flow using the smaller target capturing roughly three times the bandwidth of its counterpart. This unfairness stems from measurement noise and differing feedback delays, which amplify the advantage of the more aggressive configuration. The authors therefore caution that heterogeneous LEDBAT settings or varying network conditions can lead to significant intra‑protocol inequity.
Finally, the paper warns that misconfiguration—particularly an overly large target delay—can cause LEDBAT to compete as aggressively as TCP, negating its low‑priority intent and potentially worsening congestion. The authors recommend adhering to the standardized default values and suggest future work on dynamic, self‑adjusting parameter mechanisms, multi‑path fairness, and hybrid LBE designs that combine the strengths of LEDBAT with other low‑priority protocols.
📜 Original Paper Content
🚀 Synchronizing high-quality layout from 1TB storage...