Micro Transport Protocol (µTP) in Java Ivan Iljkic Zürich, Switzerland Student ID: 06-920-854 – Communication Systems Group, Prof. Dr. Burkhard Stiller HESIS T Supervisor: Daniel Dönni, Thomas Bocek, Andri Lareida ACHELOR Date of Submission: January 1, 2006 B University of Zurich Department of Informatics (IFI) Binzmühlestrasse 14, CH-8050 Zürich, Switzerland ifi Bachelor Thesis Communication Systems Group (CSG) Department of Informatics (IFI) University of Zurich Binzmühlestrasse 14, CH-8050 Zürich, Switzerland URL: http://www.csg.uzh.ch/ Abstract Transfer of large files like P2P file sharing traffic and software updates are less sensible to long delays and low bandwidths. But especially P2P file sharing clients gain an unfair advantage over applications like VoIP when managing multiple TCP connections. LED- BAT is an experimental algorithm that aims to manage background traffic in order to free up bandwidth for more interactive applications. An implementation of the algorithm is already in use in some P2P file sharing clients, known as µTP (Micro Transport Protocol). This paper discusses UTP4J, an Java implementation of µTP for scientific projects. The goal is to provide an easy-to-integrate, configurable and stable library for experimental purposes. It covers the API, architecture and implementation details of UTP4J. Further, an evaluation of UTP4J's behavior is given. This includes experiments with the congestion control mechanism during concurrent TCP traffic and ways to make µTP more aggressive under the influence of concurrent traffic. i ii Zusammenfassung Die Ubertragung¨ von grossen Dateien in P2P-File-Sharing-Applikationen und grossen Software Updates ist oftmals weniger sensibel was lange Delays und begrenzte Bandbre- iten angeht. Aber Speziell P2P-Clients erhalten einen unfairen Vorteil gegenuber¨ anderen Applikationen wie VoIP, wenn sie mehrere TCP-Verbindungen unterhalten. LEDBAT ist ein experimenteller Algorithmus, der sich zum Ziel gemacht hat, Background-Traffic zu managen, um gegebenenfalls mehr Bandbreite fur¨ interaktivere Applikationen freizugeben. Eine Implementation, bekannt als µTP (Micro Transport Protocol) des Algorithmus ist schon bei einigen P2P-Clients im Einsatz. Diese Arbeit stellt UTP4J vor, eine auf Java basierende Implementation von µTP fur¨ wis- senschaftliche Zwecke. Das Ziel ist es, eine einfach zu integrierende, konfigurierbare und stabile Bibliothek fur¨ experimentelle Zwecke zur Verfugung¨ zu stellen. Das Dokument beschreibt die API, Architektur und Implementationsdetails von UTP4J. Desweiteren wird das Verhalten von UTP4J evaluiert. Dies umfasst experimente mit dem Staukon- trollmechanismus w¨ahrend nebenl¨aufigem TCP-Verkehr und Wege, UTP4J aggressiver zu machen. iii iv Acknowledgments I would like to thank Prof. Dr. Burkhard Stiller and the Communication Systems Group for giving me the possibility of working on such an exciting topic. I would also like to thank my supervisors, Danni, Thomas and Andri for all the patience they had and all their valuable input which made this work possible. v vi Contents Abstract i Zusammenfassung iii Acknowledgments v 1 Introduction 1 1.1 Managing Background Traffic . .1 1.2 Buffering Delay . .2 1.3 LEDBAT Essentials . .3 1.4 µTP .......................................3 1.5 ThesisOutline..................................3 2 Related Work 5 3 Requirements 7 4 Design 9 4.1 API Design . .9 4.2 Architecture . 10 4.3 Design Decisions . 10 vii viii CONTENTS 5 Implementation 13 5.1 Connection Setup . 13 5.2 Writing Implementation . 13 5.3 Algorithm .................................... 14 5.3.1 Waitingtime .............................. 14 5.3.2 Retransmission Timeout . 15 5.3.3 Clock Drift Correction . 15 5.3.4 Configuration . 16 5.4 Reading Implementation . 16 5.5 ReceivingPackets................................ 17 5.6 DataTypes ................................... 17 5.7 Timestamping.................................. 17 6 Evaluation 19 6.1 Test Environment Setup . 19 6.2 TCP Reference . 20 6.3 OptimalParameters .............................. 20 6.4 OptimalTargetDelay ............................. 23 6.5 µTP competing with concurrent traffic . 26 6.6 µTP Aggresivity . 28 6.7 Compatibility to libutp . 29 7 Summary and Conclusions 31 8 Future Work 33 Bibliography 35 Abbreviations 37 List of Figures 37 CONTENTS ix List of Tables 39 List of Listings 41 A Important Configuration Parameters 45 B Installation Guidelines 47 C Contents of the CD 49 x CONTENTS Chapter 1 Introduction Internet traffic can be roughly categorized into two different groups. The first group is the so called foreground traffic and its Quality of Experience (QoE) is sensible to long delays and limited bandwidth. Such traffic is caused by interactive applications like VoIP, media streaming and online gaming. For example, the International Telecommunications Union recommends a 150ms one-way delay to be acceptable [1]. On the other hand, there is also traffic, that does not suffer from bad connections. This kind of traffic usually is not interactive and thus not sensitive to long delays or limited bandwidth. Traffic caused by P2P applications or large software updates belong into this group of background traffic. 1.1 Managing Background Traffic TCP is the internet's most common transmission protocol and seeks to share the available bandwidth evenly across all connections. However, one would want foreground traffic to be prioritized over background traffic and when there is no foreground traffic, the internet link should be still fully utilized. An even worse scenario is, when a background application, like a Bit-torrent client, manages multiple TCP connections. In this case, the Bit-torrent client would gain an unfair advantage over a more interactive application which only holds one TCP connection at a time and therefore its QoE would decrease. There are still options to limit the bandwidth utilization of a P2P client, but these settings require manual interaction each time when bandwidth is needed for more important applications and when the bandwidth can be fully used again. This solution is suboptimal [2]: The user needs to configure his client after installing it Knowledge about the available bandwidth is required for all networks Figuring out the optimal numbers is difficult. A wrong guess may waste bandwidth or not be sufficient. 1 2 CHAPTER 1. INTRODUCTION A mechanism to negate the disadvantages is desired. Ideally, it should all be done dynam- ically with a short response time. The mechanism should detect foreground traffic when it is present and reduce background traffic to the point where it no longer interferes with foreground traffic. On the opposite, when foreground traffic disappears, the mechanism should utilize the full available bandwidth. A good way to detect the competitive traffic is to keep an eye on the congestion situ- ation in the network. Typically, network devices have a buffer where packets temporary reside until the device processes the packet. When the buffer is full, routers usually will start to drop incoming packets. TCP's way to detect congestion is based on this principle. Every time TCP registers a packet was lost, it will halve its sending rate. However, at this point, the network is already congested. And after TCP has slowed down because of a lost packet, it still will start to gradually increase its sending rate until the next packet loss occurs due to a full buffer somewhere in the network. 1.2 Buffering Delay Yet a better way to detect competitive traffic is to look at the buffer utilization and react before it is completely filled. This can be achieved by measuring the one-way delay of an existing connection. There is no point in interpreting a delay value without a reference. An application can open a connection which will be routed through an already congested part of the network. In this case, the delays will always be high and it is difficult to tell whether the network is congested or the delays are high because of an other reason. Finding a generally accepted reference value is also difficult, as there are transmissions mediums with different delay characteristics. There are three factors which cause delays (δ) in a network transmission [3, 4]. The first one is the time the data spends traveling trough the transmission medium (τ). This can be calculated as the the length of the medium divided by the velocity the signal trav- els through the medium. The second is the routing delay (ρ). That is the time, a router spends to analyze the packet headers and figuring out where to forward the packet. And finally there is the buffering delay (β): the time, a packet spends waiting in buffers. If all packets are routed through the same routers, τ and ρ will stay constant. The only influenceable part by a sender is the buffering delay β. If a router has to process more packages, β will increase and vice versa. The problem can be reduced now. In order to track the congestion situation of a network, the sender needs to periodically measure the one-way delay and find out the values for τ and ρ. The LEDBAT algorithm [4] (for Low Extra Delay Background Transport) does this by keeping track of the minimum delay δmin. Assuming, that every once in a while, a packet will travel through the network without any buffering delay, LEDBAT concludes that this must be the base delay δbase = τ + ρ = δmin since β = 0. With this value, LEDBAT can estimate the buffering delay βn for each packet sent by comparing its delay with the base 1.3. LEDBAT ESSENTIALS 3 delay: βn = δn − δbase = (τ + ρ + βn) − (τ + ρ) 1.3 LEDBAT Essentials LEDBAT uses, just like TCP, a congestion window (CWND) to control its send rate. CWND is defined as the amount of data, that the sender is allowed to send in one round cwnd trip time (RTT). Thus the send rate can be defined as sendrate = RT T . Each outgoing packet has an attached time stamp. The receiver compares the incoming time stamp with a local one and returns the difference in the acknowledgment (ACK). The sender inter- prets this difference as a delay measurement of the packet that was just ACKed.