A taxonomy based perspective of the design trade offs for bittorrent like protocols

A TAXONOMY-BASED PERSPECTIVE OF
THE DESIGN TRADE-OFFS FOR
BITTORRENT-LIKE PROTOCOLS
WANG YOUMING
(B.Eng.(Hons.), NUS)
A THESIS SUBMITTED FOR THE DEGREE OF MASTER OF SCIENCE
DEPARTMENT OF COMPUTER SCIENCE
SCHOOL OF COMPUTING
NATIONAL UNIVERSITY OF SINGAPORE
2013
Acknowledgements
First and foremo st, I would like to thank my supervis or Prof. Ben Leong,
who has taught me and guided me in many ways for the past four yea rs.
He taught me in the Facebook class (CS3216), ment ored me in the CVWO
projec t , employed me to work as a research assistant on the TFTTP projec t and
supervised me to complete this Master thesis in t he end. I have learned many
useful lessons from h im, not only abo ut research, but also more importantly
about life. His words are insightful, his conduct is a l ive demonstration of his
core belief. His passion for teaching and spirit of striving for excel l ence have
deeply affected me. I think I am going to pursue a career in education sector
as well, since to in culcate my knowle dge to my students through tea ching is
one of the greatest delights of my life. I am deeply gratefu l to Ben for helping
me to find my calling.
I also owe my gratitude to Pro f Teo Yong Meng for guid i ng me in many
ways in my researc h work. His strong ba ckgrou nd and experience of network
system research has broaden my thinking an d helped me to conduct my work
in a more systematic ways.
I would like to thank my colleagues Dr. Su Wen and Cristina. Both of them
are more senior than I a nd have more research experience than I d o. They
pointed out my limitation in my thinking and experiment de sign and suggest

many useful improvements, and helped m e to better adapt to the research
enviro nment.
I would like to thank my friends Guo Xiangfa and Liu Xiao who has made
my NUS life more memo rable. I also would l i ke to thank Wang Wei, Xu Yin,
Gong Jian, Yu Gu oqing, Leong Wai K ay, Daryl Seah and Ali R azeen for being
my wo nderful and helpful lab mates.
I owe my deep gratitude to my parents for loving me and praying for me,
especially during my life in Singapore. They are wonder f ul parents who I
cherish deeply and dearly . I would like t o thank my newly ma rried wife Kang
Pei for accompanying me for the past one and half years through my joy and
ii
sorrow, my wellness and sickness. Her presence has brought much delight to
my life . I thank God for His blessing by bringing her into my life.
Last but certainly th e most importantly, I wou l d li ke to t hank my Savior
and Lord Jesus Christ. His love to me surpasses knowledge and is everlasting
and ever fresh. I would like to dedicate my whole life to experience His love
and love Him in return.
iii
Ta ble of Contents
1 Introduction 1
1.1 Our Approac h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Contributio ns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Report Orga nization . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Related Work 6
2.1 Analysis, Simulation and Measurement Studies . . . . . . . . . . 6
2.2 Strategic BT Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 BT Protocol Design Space . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Investigati ng the P rotocol Design Space 12
3.1 Overview of BT-like Protocols . . . . . . . . . . . . . . . . . . . . . 13
3.2 Experiment al Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Number of Connections . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Number of Unchokes . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 Number of Optimisti c Unchokes . . . . . . . . . . . . . . . . 26
3.5 Peer S election Strategy . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.1 Choice of Peers for Optimistic Unchokes . . . . . . . . . . . 32
3.5.2 Choice of Peers for Regular Unchokes . . . . . . . . . . . . . 35
3.6 Uplink Bandwidth Allocation . . . . . . . . . . . . . . . . . . . . . . 38
3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Design Principles 40
4.1 Keep Promise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Keep Neighbour In f ormation Up-t o-date . . . . . . . . . . . . . . . 43
5 Conclusion 44
5.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
iv
List of Tables
3.1 Equal-split rate of BTold vs BTnew . . . . . . . . . . . . . . . . . . 26
3.2 regula r unchoke strategy and performance result . . . . . . . . . 36
3.3 Utilization o f BitTyrant and PropShar e . . . . . . . . . . . . . . . . 39
4.1 Comparison of experiment results for Azureus an d FairTorrent . 41
4.2 Comparison of experiment results with HAVE a ggregation turn
on and off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
v
List of Figures
1.1 Taxonomy of BT variants. . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Plot of finish times a gainst server upload band width. Best client
finish time is the download compl etion time of the fastest client
in the system. Unique pieces finish time is the time needed by
the server to issue out all pieces of the downloaded file at least
once to some peer in the system. . . . . . . . . . . . . . . . . . . . 16
3.2 Average download ti me of BT peers when varying the number of

connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Comparison of upload bandwidth utiliz ation for different num-
bers of connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 The percentage of matched regul ar u nchokes over time for dif-
ferent peer set size. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 The perc entage of roughly mat ching reg ular unchokes for ea ch
bandwidth groups over time for peer set size = 90. . . . . . . . . . 20
3.6 Average download time of BT peers w hen varying t he fixed num-
ber of unchokes from 4 to 40 with step of 3. Error bars indicate
the standard deviation. The client upload capa cities are hetero-
geneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Average download time of BT peers w hen varying t he fixed num-
ber of unchokes from 1 to 10, with step of 1. Error bars indicate
the standard deviation. . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.8 The ma t ching gr aph of upload amount vs download amount fo r
all pee rs when time = 400s. . . . . . . . . . . . . . . . . . . . . . . 25
3.9 Average download ti me of BT peers when varying the number of
optimistic unchokes for non seeding case. Error bars indicate the
standard deviation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.10 The ma t ching gr aph of upload amount vs download amount fo r
all pee rs when all nodes run BT clients when t i me = 400s. . . . . 28
3.11 Average dow nload t i me and fairness index of BT peers when
varying the number of optimistic unchokes. . . . . . . . . . . . . . 29
vi
3.12 Average download ti me of BT peers when varying the number of
optimistic unchokes for seedi ng case. Error bars indicate the
standard deviation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.13 The func tion that Azureus uses to calculate and locate the p eer(s)
from the peer list ordered according to descending order of deficit
for opt i mistic unchokes . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.14 The percentage of exactly and roughly matched regular unchokes
over time for rando m optimistic unchokes and factor of recipro-
cation consi deration. . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.15 The percentage of exa ctly matched optimistic unchokes ov er time
for random optimistic unchokes and factor of reciprocation con-
sideration for peers with upload capacity of 100 KB/s and 150 KB/s.
34
3.16 The percentage of exac t l y matched regular unchokes over time
for random optimistic unchokes and factor of reciprocation con-
sideration for peers with upload capacity of 50KB/s. . . . . . . . 3 5
3.17 The percentage of exa ctly matched optimistic unchokes ov er time
for random optimistic unchokes and factor of reciprocation con-
sideration for peers with upload capacity of 50 KB/s. . . . . . . . 36
3.18 The ma t ching gr aph of upload amount vs download amount fo r
all pee rs when time = 400s. . . . . . . . . . . . . . . . . . . . . . . 37
3.19 Comparison of upload bandwidth utilization among peers run-
ning B T, BitTyrant and PropSh are. . . . . . . . . . . . . . . . . . . 38
4.1 Number of CANCEL messages rec eived for each 10 secs interval
and th e correspond i ng average u pload rate of peers. . . . . . . . . 42
4.2 Ti me taken to ser ve each reques t . Requests are ordered acc ord-
ing to service time. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
vii
Abstract
In recent years, Bit Torrent (BT) has become the most popular peer-to-peer file
sharing protoc ol. However, in spite of its popularity, t he protoc ol has many
vulnerabilit i es that can b e exploi t ed by s trategic peers. Some recent work
studied the trade-offs involved in BitTo rrent algorithm, b ut the exploration
of the design space has not been comprehensive. In t he dissertation, we
propose a new taxonomy-bas ed app roach for analyzing the tra de-offs in a
practical implementa tion of the BT protocol and inves t i gate these trade-offs

in t he p rotocol design space. Finally, we propose two key design principles
we gleaned from our experience working with various BT clients: (i) keeping
promises and (ii) keeping inform ation up-to-d ate.
viii
Chapter 1
Introduction
BitTor rent (BT) [5] has in rece nt years become the predominant means for
peer-to-peer (P2P) content distribut i on on th e Internet. A numbe r of BT vari-
ants have also been proposed over the past few years to address various is-
sues like fairness [16] and strategic peers [13, 14]. Given its importance to file
sharing, it is im portant to understand how different elements in the protocol
will affect perf ormance.
To the best of our knowledge, Fan et al. [6] wer e the first to propose a math-
ematical mode l that allows us to tradeoff performance for fairness in BT by
adjusting the ratio of regular unchokes to o ptimistic u nchokes in BT protocol.
We found that in a ddition to this ratio, the re are many other mech anisms that
can affect the trade-offs between performance and fairness tha t are not cap-
tured in their model. We believe that because the impl ementation of the BT
protoc ol is inherently comple x, the trade-off between performance and f air-
ness cannot be adequately captured with a limited mathemati cal framework,
such a s the one proposed b y Fan et al.
1
1.1 Our Approach
Theref ore, we propose a new taxonomy-based app roach for analyzing the
trade-offs that takes into consideration the practical impl ementation of the
BT protocol. To this end, we analyzed a number of the available BT var i ants,
including BitT yrant [14], BitThief [13], PropShare [11], F airTorrent [16] and
Azureus 3.0.4 [1], and compared them to the defau l t BT p rotocol [5] to come
up with a taxonomy, based on the following four key decisions made by the
various protocols:

1. Number of connections , i.e. how many peers does each node connect
to?
2. Number of unchokes, i.e. how many peer s does a node service simulta-
neously?
3. Peer selection strategy, i.e. how does a node decide which peer(s) to
unchoke?
4. Uplink bandwidth allocation, i.e. how much d ata is to be uploaded to
each u nchoked pee r?
The resulting taxonomy is shown in Fi gure 1.1.
We modified the Azureus BT client to comply with the b ehaviour of original
BT proto col to act as the baseline comparison and added additiona l code to
record key ac tivities, like choke messages. We also augmented the client with
additional command-line arguments to allow us easily change various param-
eters and modified the clien t to support both seeding mode a nd non-seeding
mode, where nodes leave immedia t ely upon completing a download. We did
the same for the other clien ts like BitTyrant [14], PropShare [ 11] and FairTor-
rent [1 6]. We also modified the choke/unchoke algorithm to include new one,
2
peer selection
# unchokes
upload rate
control
# connections
unchoke some
unchoke all
FairTorrent
unchoke
optimistic
random
prioritized

unchoke
optimistic
upload
none
to be
BitTyrant
BitThief
PropShare
Default BT
Azureus 3.0.4
none
weighted
average
minimum
unchoked
connect to
some
connect to
all
BitTyrant
Figure 1.1: Taxonomy of BT variants.
like unchoking algorithm that was ba sed on deficit to allow us to compare the
performance of different algorithms for peer selection strategy.
We conducted experiments on PlanetLab using 100 nodes and 3 servers.
We chose a wide range of upload capacity for our nodes in order to mimic the
hetero geneous environment in real world. We looked into the possible options
for each decision by gathering from previous works and our own proposed
ideas. We collected logs from each node of each experiment and wrote scripts
to process them to give us data we like to analyze. We plotted various parame-
ters, li ke uplo ad rate, client matching, utilizat i on, etc. to help to visualize the

interval m echanics of each option and compare their differences in term of
fairness and performance. We invest i gated fairness and performance at bo th
the systematic and at the individual level. Though we realized that some of
the protocol decisions are related to o ne another, we try to separate them as
3
much as possible so that we can analyze and study them individually to give
us some usef ul insig ht.
1.2 Contributions
By s ystematically studying the differences between the various BT variants
with o ur taxonomy-based approach, this dissertation makes th e following
contributions:
1. Detailed Invest i gation of Protocol Design Space. Our detail ed and
systematic exploration of the design spac e for the BT p rotocol reveals
more design knobs than th ose suggested by Fan et al. [6], including dif-
ferent pee r sel ection strategies and data upload control. In p articular, we
show that the peer se l ection can have significant impact on performance
and fa i rness.
2. Design Principles. From our exp erience working with the various B T
variants, we al so articulate two key pr inciples that we found are impor-
tant to achieve good performance:
• Keep promises, i.e. requests should be serviced promptly;
• Keep the neig hbour information up-to-date.
1.3 Report Organization
The rest of this dissertation is o rganized as follo ws: in Chap t er 2, we pro-
vide an overview of the related work in t he l i t erature. In Chap t er 3, we de-
scribe each level of taxonomy framework along with an associa t ed measure-
ment study. In Chapter 4, we present the key principles along and investiga te
4
how they can affect practical performance. Finally, we discuss future work
and co nclude in Chapter 5.

5
Chapter 2
Related Work
In this chapte r, we first pres ent a ge neral overview of previous studies that
reveal some of its key vulnerabilities of the BitTorrent protocol. Next, w e
describe several prominent strategic BT clients in chronological order. Finally,
we highlight some studie s which focus on a high- l evel understanding of the
BT protocol design space.
2.1 Analysis, Simulation and Measurement Stud-
ies
There are a large numbe r of analysis, simulatio n and measurement studies
on BT performance in the literature. Legout et al. [10] claimed that rarest
first and choke algo rithm is enough to enc ourage reciprocation and preven t
free-ri diing and later showed experimentally that clustering and good sharing
incentive in BT systems [9]. The inherent w eaknesses of the BT protocol has
also been ext ensively stud i ed [17, 7, 2, 12].
Thommes et al. found that peer selection and unchoking techniques in de-
fault BT imp lementation can induce subst antial unfairn ess a nd proposed the
use of a cond i t i onal optimistic unchoke to reduce the altruism introduced in
6
unnecessar i l y optimistic unchoke [17]. They also suggested multiple connec-
tion chokes and variabl e num ber of unchokes to allow more flexibility on how
many peers to unchoke and who to unchoke in orde r to improve fa i rness.
Jun et al. mode l l ed the incentives of BT as an iterated Prisoner’s Dilemma
proble m and showed with PlanetL ab experiments that free riders compl ete
downloads as early as those who contributes to t he swarm [7]. To addr ess
such unfairness, th e y proposed that a restriction be imposed on the differ-
ences of up l oad amount and download amount for each link to a certain
bound at all t i mes.
Bharambe et al . found that BT’s rate-based Tit-For-Tat (TFT) policy can

give rise to unfairness across nodes in term of t otal data served in hetero-
geneous environment [2]. They proposed a pair wise block-le vel TFT which
reduces unfairness , which is essentially the equivale nt to the scheme pro-
posed by Jun e t al. [7]. The resulting trad e-off is a reduction in utilization,
which is especially severe among faste r peers. This is because the faster peers
are more likely to stop uploading to its neighbours whenever the block-level
TFT co nstraint is not satis fied.
Liogkas et al. stu died the effec t of selfish BT clients, which attempt to
download more than their fair sha re [12]. They identified three exploits, down-
loading only from se eds, do wnloading only from fastest peers and advertising
false pieces. Their experimental results showed that BT proved to be quite
robust against these exploits. H owever, the paper only studied each exploit
individually , therefore the effect of benefits may be greater if all exploits are
employed at the same tim e.
7
2.2 Strategic BT Clients
Many differe nt BT clients have been invented to exploit or fix the various
strategic vulnerabilities. BitThief [1 3] is a free-riding BT client that attempts
to download data without contributing to the swarm by uploading data at
all. BitThief tries to e stablish much more connections than the official client
which allows it to obtain da t a from more seede rs and get more optimistic
unchokes from leechers. BitThief can ac hieve a hi gh download r ate, which
showed that the basic piece exchange mechanism i s ineffec t ive at restrain i ng
free-ri ding peers.
Piatek et al. studi ed three different instances of altruism in BT-like pro-
tocols, namely the matching period, regular uncho kes and opti mistic un-
chokes [14]. To take advantage of the altruism, they propose a BT variant
called BitTyrant that uses greedy peer set size ( i . e. number of connecti ons)
which was proposed in BitThief [13] and greedy uplink allocation. Instead
of treating unchoked peers equally, b y not limiting on how much data can

be uploaded to unchoked peers, BitTyrant attempts to upload only the min-
imum amount of dat a to ea ch unchoked peer so as to secure and main tain
the peer’ s rec i procati on. In other words, the BitTyrant client seeks to ma x-
imize the total data download rate by actively ma naging the data uploaded
to each peer. Carr a et al. subseque ntly showed that the performance gain of
BitTor rent over BT is due to the increased number of connections established
by BitTyrant peers, rather than to the alleg ed active upload management [3].
However, this study was limi t ed to simul ation. In our work, we verifi ed that
the perform ance of B itTyrant is not as good as that claimed in the original
BitTyrant paper [14] through experiments o n PlanetLab.
Laoutaris et al. developed an uplink allocation algorithm that can shorten
the download time by improving uplink utilization by dynamically managing
8
the number of unchokes in real-time [8]. Whi l e keeping the upload capacity
of the peer is fully utilized, they try to minimize th e number of unc hokes
by uploading to the nodes wit h high upload capacity and low availabi l i ty of
pieces. This minimizes the risk of under-utili z ation of neighbours. However,
since Laoutaris et al.’s protocol requires the peers to be coopera t ive, their
scheme may not be realistic in a real-world scenario.
PropShare was proposed to address the loopholes in original BT algorithm
which were exp l oited by BitThief a nd BitTyrant [11]. PropSh are controls the
rate of data upload by assigni ng each peer with an upload limit equal to the
weighted average of the data receiv ed from the previous few rounds. Levin et
al. showed that PropShare is Sybil-proo f and c ollusion-resistant. However, the
PropShare client needs to know its initially available upload capaci t y an d only
therea f ter can it allocate a preset upload quota for each connection. Further-
more, the upload quota of each connection may no t be fully utilized, which
would result in wasted bandwidth. Nevertheless, PropShare outperforms Bit-
Tyrant when they a re in the same sw arm and BitT yrant cannot game Prop-
Share. This is beca use PropShar e clients do no t use any upload threshold t o

decide w ho to unchoke, so there is no wa y for BitTyrant to determine what
minimum value to upload in order to win a bid for reciprocation.
FairTo rrent [16] is an innov ative algorithm similar to PropShar e that tries
to add ress the problem of unfairness in origina l BT protocol without the need
of neigh bours’ bandwidth estima tion, risk of under-utilization and compl i -
cated parameter tuning in previous attem pts by other works. Basically it
does not choke any connections, but instead prioritizes uploads ac cording to
difference of num ber of bytes uplo aded and d ownloaded from any p eer, which
is called deficit. The general idea is that the request from th e peer which
has the least deficit will be served first. This app roach can achieve fairness
naturally, however we will show in Section 4.1 th at it c an result in starvation.
9
2.3 BT Protocol Design Space
Fan et al. pro posed a mathematical framework to study the fairness and per-
forman ce of a P2P file sharing network [6]. They showed that there is a fun-
damental trade-o ff between perfo rmance and fairness. However, they only
investigated performance and fairness from a theoretic al per spective, and the
actual algorithm for various BT-varia nts are not fully explored. F or exam-
ple, the paper assumes tha t each peer divides its uploading capacity equa l l y
among its neighbours. This is certainly not the case for BitTyrant, PropShare
and FairTorrent. The paper prese nts only one design knob to t une fairness
and per f ormanc e based on original BT, which is by tuning number of regu l ar
unchokes and optimi stic unchokes. In a practical BT implementation, the de-
sign knobs are certainly more complicated that this. Furthermore, Fan et al.
did not seem to un derstand original purpose of o ptimistic unchokes. While
an optimisti c unchoke is altrui stic since it w i ll give to others first, its purpos e
is to explore the available peers to i dentify those that can r eciproc ate at a
faster rate than current set of peers that are unchok ed by regular unchokes.
Optimistic unchokes are theref ore not altruistic by design , but rather, the al-
truism is a side-effect. Therefore, the scenario where all the peers u se only

optimistic unchokes only t o serv e other people is not realisti c in an actual
real-w orld environment.
Xia et al. surveyed existing BT pe rformance studies by adopting some ge n-
eral approaches in categ orizing ex i sting work s an d summarizing the design
issues, their effectiveness and possible improvem ents [18]. Their survey in-
cludes works fr om analysis, me asurement and simulation studies. However,
Xia et al. categorized all desi gn issues und er either piece e xchange and over-
lay topology which is unnecessari l y broad . There is no apparent relationship
between the two categories. In contrast, our work considers four factors that
10
corres pond directly to the BT protocol impl ementation, to systematically orga-
nize the design issues in a step-by-step manner, which we believe aids in our
understand i ng and appre ciation of the mechanics involved in t he BT p rotocol
and facilitate s future design of new BT-related protocol. In addition, some of
the claims summarized by Xia et al.’s s urvey paper are mutually contradic-
tory and the authors made no attempt to verify the correctness of the claims.
Furthermore, there is no clea r focus of the pa per, so the issues cov ered are
much broad er and the resultin g discussions on each issue are inev i tably very
brief. In our work, we f ocus mainly on performance and matching among
peers, which all ows us to focus on fewer issues but in the process, investigate
each issue in greater depth.
11
Chapter 3
Investigating the Protocol Design
Space
In this chap t er, we first describe our framewo r k for the proposed taxonomy of
protoc ols. We make the following ass umptions in our discussion:
• The ban dwidth bottleneck is in the uplink instead of the downlink at the
nodes. This as sumption is consistent wi th previous work [6].
• Peers will attem pt to ful ly utilize the upload capacity as long as they can

achieve good download r ate.
Next, we investig ate how the following parameters affect BT performa nce by
running exp eriments on the Pla netLab testbed [15]:
• Number of connections
• Number of Unchokes
• Peer Selection S trategy
• Uplink Bandwit h Allocation
12
3.1 Overview of BT-like Protocols
In this section, we give a brief introduction to BT protocol and e xplain the
terms that are used in this dissert ation.
A P2P file sharing network is form ed by p eers that want to download
and/or upload a common file. The file is divided into fixed size pieces (typi-
cally 256 K B each), and eac h piece is further divided into sub-pieces wh ich
is called blocks, typica l l y of 16 KB in size . The peers usually simultaneously
download and upload blocks of the file from one ano ther. The peers tha t
have the c omplete file ar e called seeds and they eff ectively act as servers by
uploading p i eces to other peers.
When a peer joins a BT-based file sharing networ k, it obta ins a list of peers
from the tracker and connects to some of them. The peers exchange their
bitfield, a bit map that records what file pieces each peer ha s. Based on the
bitfield informat i on, the peers can request missing pieces from other peers.
Choking is the mechanism used to limit the number of simult aneous upload.
By unchokin g a remote peer, t he local peer informs the the re mote peer t hat it
can now request pieces from it and serv es the requests accordingly. The set
of unchok ed peers can be divided into regular unchoke peers and optimistic
unchoke peers . Nodes record how much data they download from each peer
every ten se conds, which we refer to as a time inte r val. Regular uncho ke
peers are cho sen from the remote pe ers that upload the most data blocks to
the local peer during the latest time interval accordin g to the origi nal p rotocol

specification. Optimistic unchoke peers usually chosen rand omly by a node in
an attempt to find remo t e pe ers that can upload data to it at a faster rate than
its current set of unch oked peers. Seeds and the optim i stic unchoke help to
bootstrap new peers without any file blocks to exchange with others.
There are basically two major strategies involved in the BT protocol, namely
13
peer selection strategy and piece selection strategy.
The peer sele c tion str ategy refers to how a node de cides on which peers to
unchoke. In the BT protocol, the owner of the data decid es which peers to
unchoke (upload) and will uplo ad blocks according to the req uests rece i ved
from the peers, while the unchoked peer only d ecides w hat piece to req uest.
The goal of peer selection is (i) to efficient l y utilize available upload capacity
and (ii) to obtain maximum reciproca tion from other peers. Hence, a node
needs to pick enough peers to fully utilize its upload capacity and also pick
wisely in order to maximize reciprocation from the peers.
The decision on which peer to download data from is usual l y passive. In the
original BT protocol, a peer can only request up to four piec es from neighbours
when they are unchoke, so th e peer does not really have a choice about where
it wants to download dat a from. In fact, it need not. T he more peers that
unchoke a peer, the better off is its situation. Just like i n real-lif e, a person
needs not be concerne d when there are many benevolent people around who
want t o share their wealth.
Hence, once a n ode is unchoked, the re maining question is: what piece(s)
should it try to downl oad. The de facto piece selection s t rategy in original BT
protoc ol is Local Rarest First (LRF). Since piece requests are usually pipeli ned,
two requests are o f t en s ent initially. More requests can be sent l ater if the
upload rate is foun d to be high.
3.2 Experimental Setup
To understand how various parameters affect the performance of the BT al-
gorithm, We conducted measurements o n PlanetLab [ 4, 15] with BT, Az ureus

and FairTorrent. We used Azureus version 3.0.4 as the BT client, but we mod-
ified the Azureus client to make it confo rm to original BT protocol as m uch
14
as possible . For FairTorrent, we used the implementation provi ded by Sher-
man et al. [16]. In all our experiments, the size of the file to be downloaded
is 100 MB, w hich is di vided into blocks of 16 kB with 16 blocks form i ng a
piece. In each experiment, unless specified explic i t l y, we used 10 0 nodes to
simultaneously join the system and start downloading the file from the seed.
Peer bandwidth are set to be heterogeneous, w e adopt a uniform distribution,
with the same n umber of peers having bandwidth 50KB/s, 75KB/s, 100KB/s,
125KB/s and 150 KB/s. This allows u s to study the basic perform ance of BT
clients in a heterogeneous swarm which serves as a good startin g po i nt for
study of other more com plicated distribution s in future work. For most ex-
periments, we conduct two varian t s: a non-seeding round, where the peers
will leave after completion of download, and a seeding round, where the peers
will stay and become seed s after compl etion of download.
Choice of the Upload Bandwidth for Server: Before pres enting the re-
sults from our exper iments, we shall explain the methodol ogy used to choose
an appropriate upload bandw i dth for the server. In Figure 3 . 1, we plot the
time taken for the fastest client to complete its downlo ad and also the time
taken for the initial seed to g i ve out every single blo ck of the downloaded file.
It is clear that when the server bandwidth is less than 175KB/ s, the time re-
quired by the server in issuing out all the fresh blocks imposes a lower bound
on the fin ish ti me of the faste st client. As the server bandwidth increases,
the finish ti me of t he client is likel y less affected by the se rver capacity but
more by the bandwidth distribution of peers in the sys t em. We observed that
though unique pieces finish time constantly decr eases as serve r up l oad band-
width increases, the best client finish time no longer improves with increasing
server capacity when server bandwidth ex ceeds 270K B/s. Given this obser-
vation, we used 300KB/s as our server bandwidth for all our experiments.

15
0
200
400
600
800
1000
1200
1400
100 150 200 250 300 350
Time (s)
Server bandwidth (kBps)
Best client finish time
Unique pieces finish time
Difference
Figure 3.1: Plot of finish times again st server upload bandw i dth. Best client
finish tim e is t he download completion time of the fastest client in the system.
Unique pieces finish time is the time neede d by the server to issue out all
pieces of the downloaded file at least once to some peer in the system.
3.3 Number of Connections
Peer set size is defined a s number of connections that a p eer maintains in
the official BT protocol documentation. Maintaini ng connections with remot e
peers serv es two purposes. The first is to exchange us eful information regard-
ing current pieces i n possession with one another through bitfield and “hav e”
messages. This allows a peer to calculate the avai l ability of each pie ce and
request local-rarest-first piece from other peers. The second is that fr om the
peer set, a node can try to find matching peers and unchoke them. If the
peer set size is too small, there may not be enough peers of co mpatible upload
bandwidth wit hin the group and the peer may not be able to find matching
ones and will have to work with mismatc hed p eers. Figure 3.2 shows that the

average download time is roughly constant w hen number of connections is
more than or eq ual to 30. We plot the upload utilization for different numbe rs
of connections for seeding case in Figure 3.3. It shows that a small peer set
16