📝 Original Info
- Title: BitTorrent Experiments on Testbeds: A Study of the Impact of Network Latencies
- ArXiv ID: 1003.5746
- Date: 2010-04-08
- Authors: ** - Ashwin Rao (INRIA, France) - Arnaud Legout (INRIA, France) - Walid Dabbous (INRIA, France) **
📝 Abstract
In this paper, we study the impact of network latency on the time required to download a file distributed using BitTorrent. This study is essential to understand if testbeds can be used for experimental evaluation of BitTorrent. We observe that the network latency has a marginal impact on the time required to download a file; hence, BitTorrent experiments can performed on testbeds.
💡 Deep Analysis
Deep Dive into BitTorrent Experiments on Testbeds: A Study of the Impact of Network Latencies.
In this paper, we study the impact of network latency on the time required to download a file distributed using BitTorrent. This study is essential to understand if testbeds can be used for experimental evaluation of BitTorrent. We observe that the network latency has a marginal impact on the time required to download a file; hence, BitTorrent experiments can performed on testbeds.
📄 Full Content
arXiv:1003.5746v1 [cs.NI] 30 Mar 2010
BitTorrent Experiments on Testbeds: A Study of the
Impact of Network Latencies
Ashwin Rao, Arnaud Legout, and Walid Dabbous
INRIA, France.
{ashwin.rao, arnaud.legout, walid.dabbous}@inria.fr
Abstract—In this paper, we study the impact of network
latency on the time required to download a file distributed using
BitTorrent. This study is essential to understand if testbeds can
be used for experimental evaluation of BitTorrent. We observe
that the network latency has a marginal impact on the time
required to download a file; hence, BitTorrent experiments can
performed on testbeds.
I. INTRODUCTION
Testbeds such as PlanetLab and Grid5000 are widely used
to study the performance of communication protocols and
networking applications. One commonly used practice while
performing experiments on such testbeds is to run multiple in-
stances of the application being studied on the same machine.
However, one primary shortcoming of this approach is the
absence of any network latency between the instances of the
application running on the same machine. Further, in experi-
ments involving more than one machine, the latency between
the machines present in the same local area network (LAN)
is negligible. In this paper we study the impact of network
latency on the outcome of experiments that are performed on
testbeds to evaluate the performance of BitTorrent.
The BitTorrent Protocol internally uses the Transmission
Control Protocol (TCP) while distributing the content [1].
The steady-state throughput of TCP is function of the round-
trip time (RTT) [2]. Further, the slow start and congestion
avoidance phase of TCP introduce a ramp up period which is
required to attain a throughput equal to the minimum of the
network throughput and the rate at which the application is
sending data. This ramp up period is a function of the RTT
and the rate at which the data is being uploaded. BitTorrent
allows the users to limit the rate at which data is uploaded;
as the time duration of an upload by a peer is in the order of
seconds, we believe that the time required to transfer pieces of
a file is not affected by such variations in the TCP throughput.
Our experiments show that the RTT (and hence the latency)
between the peers in the torrent has a marginal impact (less
than 15%) on the time required to download a file.
The details of the methodology and the tools used are pre-
sented in Section II. We initially assume the latency between
any two peers in the torrent to be the same (homogeneous
latency); the impact of homogeneous latency on the time
required to download a file are presented in Section III. The
results without this assumption are presented in Section IV,
followed by the conclusions in Section V.
II. METHODOLOGY
In this paper we use the terminology used by the BitTorrent
community. A torrent, also known as a BitTorrent session or a
swarm, consists of a set of peers that are interested in having
a copy of the given content. A peer in a torrent can be in two
states: the leecher state when it is downloading the contents,
and the seed state when it has a copy of the content being
distributed. A tracker is a server that keeps track of the peers
present in the torrent.
A. Experiment Scenarios
We consider a torrent consisting of one tracker and a finite
number of peers; a few of these peers are seeds, while the rest
of the peers are leechers. We assume that the peers remain in
the torrent until all the leechers have finished downloading the
file.
The metric used to study the impact of the network latency
between the peers is the download completion time, the time
required to the download the file distributed using BitTorrent.
We use the following network topologies to evaluate the
impact of latency on download completion time of a file.
1) Homogeneous Latency. The latency between any two
peers in the torrent is the same in this network topology.
This topology provides an upper bound on the download
completion time when the maximum round trip time
between the peers in a torrent is known. Further, this
setting was used to give an insight on the threshold of
the latency between the peers beyond which the latency
affects the download completion time.
2) Heterogeneous Latency. The peers are grouped together
to abstract Autonomous Systems (AS). We assume that
the latency between any two peers in a given AS is the
same and that all ASes are fully meshed. Further, we
assume that the inter-AS latency is greater than the intra-
AS latency; we also assume symmetric latency in the
upload and download links within an AS and between
ASes.
All the experiments were performed in a private torrent
consisting of one tracker, one initial seed (henceforth called
as the seed), and 300 leechers; these experiments were carried
out on the Grid’5000 experimental testbed [3]. A 50 MB file
was distributed in this torrent where the upload rates of the
leechers and the seed was varied from 10 kB/s to 100 kB/s.
As shown in Figure 1, four
…(Full text truncated)…
Reference
This content is AI-processed based on ArXiv data.