BEP 29 uTP Congestion Control and One-Way Delay

BitTorrent Enhancement Proposal 29 (BEP 29) defines the Micro Transport Protocol (µTP), a UDP-based transport protocol engineered to prevent internet connection saturation during peer-to-peer file transfers. Unlike standard TCP, which relies primarily on packet loss to detect congestion, µTP implements delay-based congestion control using the Low Extra Delay Background Transport (LEDBAT) algorithm. By continuously measuring one-way packet transit delay against a baseline, µTP detects network queuing before packet loss occurs, allowing it to yield bandwidth automatically to latency-sensitive foreground applications like web browsing, gaming, and VoIP.

The Objective of BEP 29

Traditional TCP stacks ramp up sending rates until network buffers overflow and packets drop. On residential internet connections with asymmetric bandwidth (such as DSL or cable), this behavior fills modem and router buffers—a phenomenon known as bufferbloat—causing massive latency spikes for all users on the local network.

BEP 29 resolves this by treating bulk BitTorrent transfers as background traffic (a “scavenger” class service). µTP maintains a target queuing delay (typically 100 milliseconds). If network queues build up past this target, µTP immediately throttles its transmission window back down, preventing bufferbloat while still utilizing spare bandwidth when the connection is idle.

Measuring One-Way Delay

A critical component of µTP’s congestion control is measuring one-way delay rather than round-trip time (RTT). RTT combines the transit times of both the upstream and downstream paths. Because most residential connections are asymmetric, congestion typically occurs in only one direction (usually the upstream). Using RTT would cause downstream congestion to throttle upstream transfers unnecessarily, or vice versa.

µTP isolates directional congestion through a timestamp mechanism:

  1. High-Resolution Timestamps: Every µTP packet header contains a 32-bit send_time field representing the sender’s local clock in microseconds at the time of transmission.
  2. Timestamp Echo: When the receiving peer processes a packet, it reads its own local microsecond clock and calculates the transit duration: transit_time = receiver_local_time - send_time. The receiver places this value into the timestamp_difference_microseconds field of the next packet or ACK it returns to the sender.
  3. Tracking Base Delay: The sender maintains a record of the minimum observed delay (base_delay) across a sliding time window (commonly the lowest value seen over the past 2 minutes). The base_delay represents physical propagation and serialization time over the wire when intermediate router queues are empty.
  4. Calculating Queuing Delay: The sender determines the actual queuing delay for each acknowledgment by subtracting the base delay from the current sample:
    current_delay = sample_delay - base_delay

Handling Clock Skew and Synchronization

µTP does not require synchronized system clocks between peers. Because the calculation subtracts base_delay from sample_delay, any constant offset between the sender’s clock and the receiver’s clock cancels out mathematically.

To address clock drift—where hardware clocks run at slightly different frequencies over time—µTP uses a rolling window of base delay samples divided into smaller time buckets. Old minimums regularly expire, allowing the algorithm to adapt to gradual clock drift without corrupting the delay measurements.

The Congestion Control Loop

Once current_delay is calculated, the sender compares it to the target delay (100 ms).