Project topics and materials
Get Complete Project Material File(s) Now! »
The BitTorrent protocol in a nutshell
BitTorrent represents nowadays one of the most successful example of the P2P approach. It slowly took over a key service traditionally offered by the client-server paradigm: content distribution. The strength of this protocol lies in its scalability, its the ability to work across unreliable and heterogeneous networks, and its built-in incentive mechanisms, that encourage the data exchange among nodes. Unlike traditional, client-server based, file-sharing applications, the main goal of BitTorrent is to setup an efficient system that involves a high number of hosts, called peers, which are either downloading the resource or uploading to others. To speed up content distribution and increase the number of content serving peers, the original resource is split in small fragments, or chunks, and then in smaller blocks. The torrent file is the metadata file that contains the index of all the chunks of a given content, as well as the fingerprint hash used to check the integrity of each chunk. To start the download, a peer has to retrieve the torrent file from a well known web-hosting site (phase 1). Using the information contained into the torrent file, the peer can contact a tracker, a centralized server that provides an initial list of neighbouring peers interested in the same resource (phase 2). This initial list is then periodically updated by the tracker itself and with the exchange of the lists from the neighbouring peers. Finally the peer can start to request the chunks to other peers involved in the swarm (phase 3). At the end the chunks are reassembled at the destination, once they all have been correctly downloaded. A simplified illustration of the aforementioned 3 phases is reported in Fig. 1.4.
In the following we provide an overview of the terminology used in the BitTorrent architecture and of the algorithms used to guarantee its proper functioning. Interested reader can refer to [3, 75] for additional details. Terminology. We detail here the set of terms most commonly used when describing the BitTorrent data-sharing service.
• Torrent. A torrent file (or more often simply a torrent) is a resource descriptor of the content which is shared among peers. It contains a list of the chunks in which the resource is split, as well as fingerprint for each of them, used to validate the data integrity.
• Tracker. A tracker is responsible of maintaining a list of all the peers involved in the content distribution, as well as collecting statistics on the downloading. The tracker is the only centralized element of the BitTorrent architecture.
• Seed and Leecher. A peer which is still downloading the content from others is called leecher, while it becomes a seed as soon as it has downloaded all the content. The initial seed is the peer that owns the complete resource at the beginning of the sharing process.
• Swarm. The swarm is the set of peers involved in the distribution of the same content.
Lower-than Best Effort transport protocols
In this section, we provide further details concerning two of the LBE protocols which are closer in spirit with LEDBAT, namely TCP-LP and NICE. To facilitate their comparison, we also report simple simulation results in Fig. 3.2, so to better visually highlight the relevant characteristics of each protocol. The top row of Fig. 3.2 reports the heterogeneous case where two flows employing different congestion control protocols are compared. The bottom row of Fig. 3.2 shows the time evolution of two flows employing the same LBE protocol assuming similar network conditions. More precisely, for each LBE2 {TCP − LP,NICE,LEDBAT} protocol, Fig. 3.2 depicts the temporal evolution of the cwnd of different flows in two scenarios of a simple bottleneck topology. In the inter-protocol case (top row, labeled as TCP-LBE), low-priority protocols compete against a standard TCP flow, while in the intra-protocol case (bottom row, labeled as LBE-LBE) two LBE flows compete against each other. In the figure, link capacity is set to C = 10Mbps, round-trip delay to RTT = 50ms and the buffer is B = 100MTU sized packets.
Latecomer in real networks
Similarly to the takeaway gathered via simulation, we point out that the latecomer unfairness also holds in practice, possibly leading to severe flow starvation. We show this by performing testbed experiments of the recently released BitTorrent open-source LEDBAT library [49] (named libUTP). As described above, we consider two PCs connected by a C = 10Mbps Ethernet bottleneck, where we emulate by means of netem [50] a RTT = 50ms delay. The first flow starts at time t = 0 while we let the latecomer join (and spoil) the party at t = 10 s. Backlogged transfers are started using the source code provided in [49], instrumented to produce detailed application-level logs1. Results of the experiment are shown in Fig. 4.2, whose left portion reports the congestion window of the two flows over time. As soon as the first flow starts, it increases its congestion window until the target is reached, and then settles. However, when the latecomer kicks in at t = 10 s, the congestion window of the first-comer drops until starvation. The situation persists until t = 50 s, at which time we stop the latecomer transfer: right after, the first-comer opens its congestion window again, saturating the link. This is an unfortunate situation, that can however be easily corrected as we show in the following sections.
Table of contents :
1 Introduction
1.1 LEDBAT: specification and evolution
1.2 The BitTorrent protocol in a nutshell
1.3 Related work
1.3.1 Congestion control
1.3.2 Peer-to-Peer applications
1.3.3 Recent LEDBAT work
1.4 Contributions of this thesis
I Congestion control perspective
2 Performance evaluation – Black box experiments
2.1 Methodology and Preliminary Insights
2.2 Single flow scenario
2.3 Multiple flows scenario
2.4 Summary
3 Performance evaluation – Simulation based
3.1 LEDBAT overview
3.1.1 Queuing Delay Estimate
3.1.2 Controller Dynamics
3.1.3 TCP Friendliness Consideration
3.1.4 Lower-than Best Effort transport protocols
3.2 LEDBAT performance
3.2.1 Reference scenario
3.2.2 Evaluation metrics
3.2.3 Homogeneous Initial Conditions
3.2.4 LEBDAT Sensitivity Analysis
3.2.5 LBE protocols comparison
3.2.6 LBE against LBE
3.2.7 Impact of RTT heterogeneity
3.3 Summary
4 Rethinking LEDBAT for fairness
4.1 Related work
4.2 Motivation
4.2.1 Latecomer in simulated environment
4.2.2 Latecomer in real networks
4.2.3 Current LEDBAT fairness issues
4.2.4 Impact of additive decrease
4.3 Proposed LEDBAT modification
4.3.1 Fluid model description
4.3.2 Fluid system dynamics
4.3.3 Main results
4.4 Simulation overview
4.5 Impact of traffic model
4.5.1 Chunk-by-chunk transfer
4.5.2 Backlogged transfer
4.6 Sensitivity analysis
4.6.1 fLEDBAT vs TCP
4.6.2 fLEDBAT vs LEDBAT
4.6.3 fLEDBAT vs fLEDBAT
4.6.4 Tuning for multiple-flows scenario
4.7 Appetizer to P2P scenarios
4.7.1 Single peer perspective
4.7.2 Entire swarm perspective
4.8 Summary
II BitTorrent swarm perspective
5 Impact of LEDBAT on BitTorrent – Simulative approach
5.1 Methodology and Scenario
5.2 Main results
5.2.1 Swarm population and seed behavior
5.2.2 Target heterogeneity
5.3 Summary
6 Impact of LEDBAT on BitTorrent – Experimental approach
6.1 Preliminary Insights
6.1.1 net.utp_target_delay: Target delay settings
6.1.2 bt.transp_disposition: TCP vs uTP settings
6.2 Experimental Results
6.2.1 Grid’5000 Setup
6.2.2 Homogeneous bt.transp_disposition settings
6.2.3 Heterogeneous bt.transp_disposition settings
6.2.4 LEDBAT vs TCP in a nutshell
6.3 Summary
7 Conclusion
7.1 Summary
7.2 Future work
Appendices
A List of publications
Bibliography
