| Part of a series on |
| File sharing and online piracy |
|---|
Micro Transport Protocol (μTP, sometimes uTP) is an open User Datagram Protocol-based (UDP-based) variant of the BitTorrent peer-to-peer file-sharing protocol intended to mitigate poor latency and other congestion control problems found in conventional BitTorrent over Transmission Control Protocol (TCP), while providing reliable, ordered delivery.
It was devised to automatically slow down the rate at which packets of data are transmitted between users of peer-to-peer file-sharing torrents when it interferes with other applications. For example, the protocol should automatically allow the sharing of a DSL line between a BitTorrent application and a web browser.
μTP emerged from research at Internet2 on QoS and high-performance bulk transport, was adapted for use as a background transport protocol by Plicto, founded by Stanislav Shalunov and Ben Teitelbaum and later acquired by BitTorrent, Inc. in 2006, and further developed within its new owner. It was first introduced in the μTorrent 1.8.x beta branches, and publicized in the alpha builds of μTorrent 1.9.
The implementation of μTP used in μTorrent was later separated into the "libutp" library and published under the MIT license.
The first free software client to implement μTP was KTorrent 4.0. libtorrent implements μTP since version 0.16.0 and it is used in qBittorrent since 2.8.0. Tixati implements μTP since version 1.72. Vuze (formerly Azureus) implements μTP since version 4.6.0.0. Transmission implements μTP since version 2.30.
Traditional BitTorrent runs over TCP, which only slows down once packets are dropped. This leads to the user's modem buffers being full, and web browsing, calls or games on the same line get stuck behind BitTorrent traffic. μTP addresses this by running over UDP instead and handling reliability, ordering and congestion control by itself. It is specified in BitTorrent Enhancement Proposal 29.
Each packet starts with a 20-byte header:
| Field | Bits | Description |
|---|---|---|
type | 4 | Packet type |
ver | 4 | Protocol version (currently 1) |
extension | 8 | First extension header, if any |
connection_id | 16 | Connection identifier |
timestamp_microseconds | 32 | Send time |
timestamp_difference_microseconds | 32 | Most recent measured delay |
wnd_size | 32 | Receive window in bytes |
seq_nr | 16 | Sequence number |
ack_nr | 16 | Last packet received in order |
There are five packet types: ST_DATA, ST_FIN, ST_STATE (an acknowledgment with no data), ST_RESET and ST_SYN. A connection opens with a two-way handshake: the initiator sends an ST_SYN and the other side answers with an ST_STATE. Unlike TCP, sequence numbers count packets, not bytes.
The congestion control algorithm used by μTP, known as Low Extra Delay Background Transport (LEDBAT), aims to decrease the latency caused by applications using the protocol while maximizing bandwidth when latency is not excessive. Additionally, information from the μTP congestion controller can be used to choose the transfer rate of TCP connections.
| Internet |
|---|
|
|
LEDBAT is described in RFC 6817. As of 2009, the details of the μTP implementation were different from those of the then-current Internet Draft.
μTP also adds support for NAT traversal using UDP hole punching between two port-restricted peers where a third unrestricted peer acts as a STUN server.