Micro Transport Protocol (uTP)

To better understand why BitTorrent has switched to uTP, it is im-

portant to understand the problems with TCP. Transmission Control Protocol makes use of the congestion avoidance algorithm Additive- Increase/Multiplicative-Decrease (AIMD) which combines linear growth

2.3 bittorrent overview 27 (additive increase) and exponential reduction (multiplicative decrease). MultipleTCPflows that useAIMDeventually converge to use an equal amount of bandwidth [CJ89]. Because BitTorrent is aP2Papplication,

it has multiple TCP connections in its peer sets. Consequently, Bit- Torrent receives more bandwidth than applications that use a single

TCP connection. As a result, BitTorrent affects foreground traffic like web browsing and email.

Previously, to solve this problem, nearly every BitTorrent client had the option to set a fixed bandwidth limit, meaning BitTorrent use a fixed amount of bandwidth. Let us suppose that µ is the bandwidth capability of an Internet connection, t is the bandwidth consumption of concurrent TCP flows, and b is the static bandwidth limit of the

BitTorrent client. If

(1) b > (µ − t), then BitTorrent uses too much bandwidth and in- terrupts the otherTCPconnections;

(2) b < (µ − t), then BitTorrent uses too little bandwidth and there will be µ − t − b unused bandwidth;

(3) b = (µ − t), the ideal amount of is used. But t is not constant and will soon become (1) or (2).

This is an inflexible solution. Additionally, it requires knowledge about bandwidth capabilities which may not be available to inexpe- rienced users. To solve these problems, BitTorrent has developed a new transport protocol based on UDPwith a new congestion control, LEDBAT. This algorithm detects unused head room with the one-way delay measurement and automatically adjusts the bandwidth limit b. An ideal traffic flow is depicted in Figure2.8.

If the foreground traffic—in Figure2.8 (blue)—increases, the back- ground traffic (red) should automatically throttle back. Conversely, if the foreground traffic decreases, the background traffic should take the unused head room (remaining bandwidth). This novel transport protocol is specified inBEP29[Nor10]. TheuTPheader of every packet is shown in Figure 2.9.

Micro Transport Protocol has much in common withTCP. The pro- tocol controls the connection flow with a sliding window and verifies

Optimal Bandwidth Usage ofuTP

Time

Bandwidth

uTP traffic All Traffic (except uTP)

Figure 2.8: Ideal traffic flow with foreground traffic (blue) and Micro Trans- port Protocol background traffic (red). Source: own representa- tion.

Header of auTPPacket

0 4 8 16 32

type version extensions connection ID timestamp tsnd (in microseconds)

timestamp difference ∆t (in microseconds) window size

sequence number acknowledgment number Figure 2.9: Version 1 header of a Micro Transport Protocol (uTP) packet.

Source: own representation based on [Nor10].

data integrity with the help of sequence numbers. Sequence num- bers, however, refer to packets instead of bytes. Micro Transport Proto- col also supports Selective Acknowledgment (SACK) via an extension

which is enabled by default in the reference implementation libutp3_.

In contrast to TCP,SACKis implemented using a bitmask where each

bit represents a packet in the send window. When a bit is set, the re- ceiver received this packet, and vice versa. Micro Transport Protocol initiates a connection with a two-way handshake instead the three- way handshake used byTCP. The message flow of this handshake is

shown in Figure2.10.

The initiator in Figure 2.10 sends a st_syn packet (similar to a

TCPpacket with a set syn flag) to the receiver. The receiver acknowl-

2.3 bittorrent overview 29

Two-way Handshake ofuTP

connection established Initiator Receiver SYN_SENT CONNECTED st_{_syn} CONNECTED st_state

Figure 2.10: Two-way handshake to initiate a connection between two uTP

nodes. The text on the outer edges reflects the state of the pro- tocol. Source: own representation based onBEP29[Nor10]. edges the st_syn packet with a st_state packet (similar to a TCP

packet with a set ack flag). A connection between the two machines is then established. The main difference between TCP anduTP is the novel congestion control algorithmLEDBAT.

2.3.3.1 Low Extra Delay Background Transport

The congestion controlLEDBATwas defined inRFC6817in December 2012[Sha+12]. The novel congestion algorithm uses a one-way delay measurement as the principal congestion control. This measurement works in part because the sender includes a 32-bit timestamp value in the header field of a data packet. The receiver calculates the one- way delay measurement and includes a 32-bit timestamp difference in the acknowledgment. An example of the network flow of LEDBAT

is shown in Figure 2.11.

Example of the One-way Delay Measurement

Sender Receiver tsnd ∆t = trcv− tsnd st_{_data, t} snd st_state , ∆t

Figure 2.11: One-way delay measurement as a congestion control with two uTP nodes. Source: own representation based on RFC6817[Sha+12].

The sender, as shown in Figure2.11, includes the time, tsnd in mi-

croseconds, in the data packet upon sending the packet. The receiver can then calculate the one-way delay ∆t by subtracting the tsndfrom

the time the data packet is received, trcv. The receiver returns an ac-

knowledgment that contains ∆t in the header field timestamp dif- ferences. The sender saves a history of 100 ∆t values in a vector ~h. TheuTPstack does not interpret the time difference ∆t as an absolute

value, rather as an relative value compared to previous data points. InLEDBAT, Equation (2.2) is used to determine whether to increase or

decrease the send window.

off_target =                + if min(~h) < 100 ms = if min(~h) = 100 ms − if min(~h) > 100 ms (2.2)

where: ~h = history of 100 ∆t values.

If the lowest value in vector ~h is less than 100 ms, LEDBAT increases the send window, and if it is more than 100 ms,LEDBATdecreases the

send window. If the lowest value in vector ~h is 100 ms then LEDBAT

3

L I T E R AT U R E S U RV E Y A N D R E L AT E D W O R K

In this chapter, I provide an overview of related work in the field of

P2P security with a focus on BitTorrent. The classification of related

work is according to the security requirements discussed in Section1.

According to [MS07, p. 199], there are three security requirements which must be considered in every P2P network: service availability,

document authentication, and peer anonymity.

3.1 service availability

The main task of a P2P network is to provide a certain service. In case of BitTorrent, this service is the distribution of files. Attacks that disturb this service are grouped under the term service availability. BitTorrent’s ecosystem consists of the following components: leecher, seeder, peer discovery, and torrent discovery. Vulnerabilities in each of these components can disturb the availability or efficiency of Bit- Torrent.