Etude et proposition d\'un protocole améliorant les transferts en Bittorent. Ces travaux d\'initiation s\'appuient sur ceux de Ratzin, Liogkas et Majumdar.

1. TEAM INCENTIVES IN BITTORRENT SYSTEMS
`
INITIATION A LA RECHERCHE - 2009/2010
Nacef Amine Chahata Colette Johnen
Master 2 Informatique Encadrant, Pr. en Informatique
sp´ cialit´ Syst` mes et R´ seaux
e e e e Universit´ de Bordeaux 1
e
1. INTRODUCTION IP address and port number of the tracker.
• Peer Set. It is the list of peers known by each peer with
The popular Peer to Peer (P2P) BitTorrent protocol has been whom he has open TCP connections.
estimated to be used for approximately 27-55% of all Internet • Leecher and Seed A peer can only be of two types: a
traffic. This widespread use is mainly due to its scalability leecher is a peer still downloading pieces of the con-
and robustness properties. In fact, Bittorrent Protocol is de- tent, and the seed is a peer having all the pieces and
signed for scalable content distribution. It adapts well with sharing them with others.
the number of participating clients and strives to insure a form • Choking and Unchoking. A peer A is choked by a
of fairness: clients who do not share data with others should peer B when B decides to stop sending data to A. Con-
not be able to get high download throughput. versely, A is unchoked by B when B is willing to send
However, it has been demonstrated that fairness is not always data to A.
respected, and free-riding exists and hurts the efficiency of • Choking algorithm. Also known as the tit-for-tat al-
such protocol. Free riders are selfish BT clients, who abuse gorithm, it’s the peer selection strategy used by BT
protocol mechanism to maximize their download rate without clients.
contributing to the system. A lot of researches tend to limit
the impact of Free riders. This work directly addresses this
important issue. This paper is organized as follows. First, Bit- 2.2. Bittorrent process
torrent terminology and process are described. Related work To join a torrent, a peer P downloads the metainfo file usu-
is presented in section 3. The proposed methodology is de- ally from a well-known website and contacts the tracker who
tailed section 4. Results are then presented and discussed. sends him back a peer collection randomly selected among
Conclusions are finally drawn. peers currently online. The collection possibly includes both
leechers and seeds. Then, P starts contacting peers in this
2. BACKGROUND
collection requesting pieces. A rarest-first policy is gener-
ally implemented for piece requests: a client asks for exist-
The terminology used for Bittorrent is defined hereby before
ing pieces at the smallest number of peers in its collection.
detailing the BT process.
Peers can exchange blocks with others but only make avail-
able a complete piece. The peer P , as a leecher, chooses who
2.1. Terminology
to exchange data with, using choking algorithm which favors
• Torrent. A collection of peers cooperating to down- those who uploaded to it with the highest rates. This list is
load the same content (e.g., a set of files) using the BT reconsidered and refreshed each rechoke period (every 10s).
protocol. It unchokes the fastest uploaders and chokes all the rest. The
• Tracker. The tracker is the centralized component of number of unchoking slots may be fixed or dependent of up-
the system. It is not involved in the actual distribution load bandwidth.
of the content, but it keeps track of all peers currently The choking strategy for a seed may be different. It can either
participating in the download, and it collects statistics. choose the highest uploaders or distributes the data uniformly.
• Pieces and blocks. Content transferred using BT is
split into pieces, with each piece being split into multi- 3. RELATED WORK
ple subpieces (blocks).
• Metainfo file. Also called a torrent file. It is created In this section, we only focus on articles related to BT sys-
by the content provider. It contains all the information tems incentives and works on free-riding. Qiu et al.[2] were
necessary to download the content. It also includes the the first to notice that optimistic unchokes may favour free-
1

2. riding. Seung et al. [3] showed that the original incentive uppermost. The maximum team size T is fixed to the number
mechanism is susceptible for free-riding. In [4], the authors of available unchoke slots at peers. In this study, it is set to 4.
presented a model that displays the trade-off between fair- Moreover, when forming teams, the tracker imposes two
ness and performance. [5] noticed that the choking algorithm rules for a peer joining a team in order to limit free-riding:
causes leechers to cluster together based on similar upload 1. it imposes a limit on the frequency of switching from
bandwidth. The team protocol explicitly makes the tracker one team to another, by keeping, for each peer, the his-
designate leechers in teams. [6] proposed a choking algorithm toric of team joins for a short time period.
that reallocates upload bandwidth to raise peer download. Ex-
ploiting optimistic unchokes as a free-rider is the main identi- 2. a peer can’t join a team if it has been discovered that it
fied vulnerability [6, 1, 10]. The proposed team protocol had is non-compliant with the team protocol (it lied on its
to reform this break. The article [7] presented another algo- upload bandwidth, ...). This peer is then blacklisted and
rithm that tends to choose leechers either at the beginning or not permitted to participate in teams.
the end of their download, so that free-riders are considerably The team formation process is depicted in Figure 1.
hurt. In [8], the authors present the 2Fast system which en-
ables a collector to make others download data for him. This
only improves the collector’s download rates while the team
protocol tends to improve all team members download rates.
4. METHODOLOGY
The proposed team protocol [9] tends to organize dynamically
peers of similar upload bandwidth in teams, groups of peers
that collaborate for mutual benefit. Therefore, team members
mostly exchange their data within their team and use opti- Fig. 1. Message flow for the team formation process, [9]
mistic unchokes only when absolutely needed. This limits
the bandwidth spent on random optimistic unchokes to dis- 4.2. Unchoking decisions
courage free-riding. To do this, the team protocol has been
One peer has to decide which peers to unchoke. In regular
designed into three parts, that are detailed hereby:
BT, it has two choking strategies:
• Team formation 1. regular unchokes: the peer unchokes those who upload
• Unchoking desicions data at the highest rate
• Detection and punishment 2. optimistic unchokes: the peer unchokes randomly (not
considering other’s contributions)
4.1. Team formation
The team protocol appends the team unchoke strategy: the
This process enables a peer to find a team with similar upload idea consists in uploading to other team members as much as
bandwidth and motivates him with a clear incentive to join the possible maximizing team performance. However, to avoid
team by improving his download rates. The team formation isolating the peer from the rest of the swarm, and to get new
is coordinated by the tracker, who assigns peers into teams content pieces, at least one regular unchoke is accomplished
based on their available upload bandwidth. To allocate a peer to an external peer. Consequently, the peer unchoking deci-
P with upload bandwidth Up to a team, the tracker ensures sions process is sequential as follows:
that the following range factor conditions are satisfied:
Step 1: team unchokes. a peer has to satisfy his team mem-
Umax bers, unchoking all of them. Let nT (t) be the number of un-
Up ≤ Umin .(1 + x) , and Up ≥ x ∈ [0, 1] (1) choke slots reserved for team members as a function of time.
(1 + x)
So 0 ≤ nT (t) ≤ nS − 1, since a peer always reserves at least
where Umin and Umax are respectively the slowest and fastest one slot for regular unchokes to external peers. As a remind,
upload bandwidth of the team members. There is a trade- nS = 4.
off on the value of x. A too large value penalizes fast team Step 2: optimistic unchokes. A leecher executes optimistic
members when interacting with much slower ones while a too unchokes to external peers with probability
small value causes the creation of many small size teams.
nS − nT (t) − 1
A good value of x can be calculated based on the desired PT (t) = P0 . (2)
nS − 1
pf (percentage of peers that will be members of full teams),
the size of the network N , the maximum team size and the where P0 is the probability for an optimistic unchoke in regu-
upload capacity distribution [9]. The tracker should keep pf lar BT, which depends on the implementation. We note nO (t)
2

3. the number of slots used for optimistic unchokes as a function If condition is not satisfied, the peer sends a switch-team
of time. message to the tracker to switch teams.
Note that the probability PT of independent leechers to per-
form optimistic unchokes is the same in the team protocol as 5. RESULTS
in regular BT (for nT = 0, PT = P0 ). However, for team
members, this probability decreases as more team members 5.1. Contributor performance
are served (nT increases). Those who can serve all their team
The first experiment is run with all leechers joining teams of
members at the same time perform no optimistic unchokes
size 4. The authors [9] compared results both in regular bit-
at all (for nT = nS − 1, PT = 0). In the latter case, free-
torrent and in a team enhanced system. They showed that the
riders will not be able to receive any data through optimistic
download time for all team members is improved by 10%-
unchokes. The authors demonstrate that this strategy hurts
26%. Moreover, the amount of uploaded data in teams de-
free-riders by limiting download opportunities.
creased by at least 10% (in their case, it concerns 32 contrib-
Step 3: regular unchokes. For the rest of the unchoke slots
utors out of 35), this is due to the fact that team members
(nS − nT (t) − nO (t)), a leecher selects the peers with the
accomplish significantly less optimistic unchokes. Besides,
highest uploading rates to itself that were not selected already.
this improvement would be higher with larger content. In
One exception to this strategy occurs when a leecher has
fact, larger content are composed of higher number of pieces
no data other team members are missing and thus cannot up-
which will lead to a lower probability of optimistic unchokes
load to them. Uploading via optimistic unchokes is then per-
formed only as a last resort. Thanks to this team unchoking 5.2. Free-rider performance
strategy, team member performance is improved, moreover
it tends to limit free-riding performance since the number of The authors show that the download completion time for free-
optimistic unchokes is reduced. riders decreased by more than 100% using the team system.
In fact, they receive less data from optimistic unchokes and
4.3. Detection and punishment have to depend mainly on seeds. They also show that op-
timistic unchokes by team members are higher during the
This subsection describes the mechanisms used by the com- warm-up and endgame periods.
pliant team members to detect and punish team members that
attempt to cheat the protocol for their benefit. 5.3. System robustness
Step 1 (self upload examination). Every team member keeps
track of the total amount of data it downloaded from and up- The authors evaluated the system robustness to an increasing
loaded to all other team members. We denote these, respec- number of free-riders by measuring the download completion
tively, with Di (t) and Ui (t) for a team member i at time t. time for contributors. They noticed that the team enhanced
Every team member then checks if it is providing satisfac- system is more robust than regular Bittorrent( 15% better) es-
tory service to others by verifying that the condition Di (t) ≤ pecially with a high number of free-riders. They also showed
(1 + x)Ui (t) is true for the majority of its team members (this that the download completion time for free-riders is highly
condition follows from Equation 1). If the condition is false, decreased in the presence of teams.
a compliant leecher sends a leave-team message to its team,
and a switch-team message to the tracker to switch to another 6. DISCUSSION
team.
Step 2 (team upload examination). Moreover, each team In this section, some points are discussed and perspectives are
member examines other members upload rates to check if proposed. They are split into two parts. The first concerns the
they are not lower than expected, in accordance with the con- global methodology and the second part the experiment.
Ui (t)
dition Di(t) ≤ (1 + x). If it’s not the case, an unsatisfactory
message, about a non-compliant peer i, is sent to other team 6.1. Methodology discussion
members (excluding i). Each member receiving such mes-
• In BT protocol, the number of peers to unchoke (un-
sages from the majority of its team (≥ 50%), sends an un-
choke slots) may be either fixed or depending on the
satisfactory message to the tracker. The tracker checks if
available upload bandwidth. In the proposed team
unsatisfied members are majoritary. The non-compliant peer
protocol, the authors have only studied the fixed case.
i is then removed from the team and blacklisted for a given
The other case could offer more solutions to fight free-
period of time.
riding as we suggest below.
This step allows to detect possible free-riders within the team.
• The main negative point about the team protocol is that
Step 3 (team satisfaction examination). A peer can also de-
the slowest leechers don’t improve their download time
termine its satisfaction with the team as a whole by checking
T −1 whereas in regular BT, they would benefit from opti-
i=1 Ui (t)
this condition: T −1 ≤ (1 + x). mistic unchokes to get better download rates.
i=1 Di(t)
3

4. • Detection and punishment process: When a non- robustness. In fact, it offers many properties. First it moti-
compliant peer is detected, the unsatisfied team mem- vates contributing peers to join a team by rewarding them with
bers send a message to the tracker which checks the improved download rates. Secondly, it limits the number of
majority decision and replies to all members. This optimistic unchokes by discouraging free-riders. Thus, even
procedure can be prohibitive with large teams [9]. To an increasing number of free-riders does not hurt contribut-
make this process shorter, we suggest that the tracker ing peers performance as compared to regular BT. Therefore,
assigns one peer as a team chief based on peer historic the system robustness is improved. However, the major in-
and uploads. Only the team chief can communicate convenient is that leechers with low uploads do not improve
with the tracker. This would reduce the punishment their download times. We proposed some perspectives as an
procedure time and minimize the number of exchanged alternative in section 6.
messages. However, this proposition could be critical
for security since a hacker can make himself a team 8. REFERENCES
chief. Note that the idea of a hierarchy has already
been addressed in [8] using a collector peer. [1] Nikitas Liogkas, Robert Nelson, Eddie Kohler, and Lixia
Zhang, “Exploring the robustness of bittorrent peer-to-peer
• A honest team member could be blacklisted if his self
content distribution systems,” Concurrency and Computation:
upload examination is not fast enough. Thus, a trade-
Practice and Experience, vol. 20, no. 2, pp. 179–189, 2008.
off between the three examinations steps (cf. section
4.3) is to find. [2] Dongyu Qiu and R. Srikant, “Modeling and performance anal-
ysis of bittorrent-like peer-to-peer networks,” in SIGCOMM
’04: Proceedings of the 2004 conference on Applications, tech-
6.2. Experiment discussion nologies, architectures, and protocols for computer communi-
cations, New York, NY, USA, 2004, pp. 367–378, ACM.
• Empirical upload capacity distribution: The authors
[3] Seung Jun and Mustaque Ahamad, “Incentives in bittorrent in-
show that in case of scaled upload capacity distribu-
duce free riding,” in P2PECON ’05: Proceedings of the 2005
tion, as in real Bittorrent systems, all teams are not ACM SIGCOMM workshop on Economics of peer-to-peer sys-
full due to different upload capacities. In fact, this in- tems, New York, NY, USA, 2005, pp. 116–121, ACM.
creases optimistic unchokes so that free-riders upload
[4] Bin Fan, Dah-ming Chiu, and John Lui, “The delicate trade-
capacities increases. In their example it increases by
offs in bittorrent-like file sharing protocol design,” in ICNP
25%. However they show that download times for 76% ’06: Proceedings of the Proceedings of the 2006 IEEE Inter-
of team members improved by up to 33%. The ma- national Conference on Network Protocols, Washington, DC,
jor members who did not improve their performance USA, 2006, pp. 239–248, IEEE Computer Society.
were the slowest leechers. Consequently, in practice
[5] Arnaud Legout, Nikitas Liogkas, Eddie Kohler, and Lixia
the team protocol tends to favor only high upload peers Zhang, “Clustering and sharing incentives in bittorrent sys-
and is particularly efficient when teams are full. One tems,” SIGMETRICS Perform. Eval. Rev., vol. 35, no. 1, pp.
suggestion should be to accept some peers with differ- 301–312, 2007.
ent upload bandwidth within the same team, in order
[6] Michael Piatek, Tomas Isdal, Thomas Anderson, Arvind Kr-
to maximize the number of full teams and therefore ishnamurthy, and Arun Venkataramani, “Do incentives build
to minimize optimistic unchokes which penalizes free- robustness in bittorrent,” in In NSDI07, 2007.
riding.
[7] Alix L.H. Chow, Leana Golubchik, and Vishal Misra, “Improv-
Notice that, in order to accept a lower uploader into
ing bittorrent: A simple approach,” in Proceedings of IPTPS,
a team, the number of its unchoking slots should be 2008.
adapted to its upload bandwidth. Consequently, the
size of the team should not be fixed. This proposition [8] Pawel Garbacki, Alexandru Iosup, Dick Epema, and Maarten
van Steen, “2fast: Collaborative downloads in p2p networks,”
tends to help well-behaving peers, with low upload,
in P2P ’06: Proceedings of the Sixth IEEE International Con-
join a better upload rate team and improve their down- ference on Peer-to-Peer Computing, Washington, DC, USA,
load times. 2006, pp. 23–30, IEEE Computer Society.
• In the experimental evaluation, it would be interesting
[9] Rafit Izhak-Ratzin, Nikitas Liogkas, and Rupak Majumdar,
to highlight how many times a given leecher switches “Team incentives in bittorrent systems,” in ICCCN ’09: Pro-
from one team to another, and the impact on the swarm, ceedings of the 2009 Proceedings of 18th International Con-
which is missing in this study. ference on Computer Communications and Networks, Wash-
ington, DC, USA, 2009, pp. 1–8, IEEE Computer Society.
7. CONCLUSION [10] Michael Sirivianos, Jong Han Park, Rex Chen, and Xiaowei
Yang, “Free-riding in bittorrent networks with the large view
The proposed team protocol reduces the need for optimistic exploit,” in IPTPS, 2007.
unchokes in Bittorrent while improving fairness and system
4