Give to-get algorithm-for_p2_p_video_on_demand

Give-to-Get: An Algorithm for P2P Video-on-Demand

J.J.D. Mol, J.A. Pouwelse, M. Meulpolder, D.H.J. Epema, and H.J. Sips
Department of Computer Science
Delft University of Technology
P.O. Box 5031, 2600 GA Delft, The Netherlands
E-mail: {j.j.d.mol,j.a.pouwelse,m.meulpolder,d.h.j.epema,h.j.sips}@tudelft.nl

Abstract start watching the content at the moment of his own choos-
ing.
Centralised solutions for Video-on-Demand (VoD) ser- VoD systems have proven to be immensely popular.
vices, which stream pre-recorded video content to multi- Web sites serving television broadcasts (e.g., BBC Motion
ple clients who start watching at the moments of their Gallery) or user-generated content (e.g., YouTube) draw
own choosing, are not scalable because of the high band- huge numbers of users. However, to date, virtually all of
width requirements of the central video servers. Peer-to- these systems are centralised, and as a consequence, they
peer (P2P) techniques which let the clients distribute the require high-end servers and expensive Internet connections
video content among themselves, can be used to alleviate to serve their content to their large user communities. Em-
this problem. However, such techniques may introduce the ploying decentralized systems such as peer-to-peer (P2P)
problem of free-riding, with some peers in the P2P net- networks for VoD instead of central servers seems a logical
work not forwarding the video content to others if there step, as P2P networks have proven to be an efficient way of
is no incentive to do so. When the P2P network contains distributing content over the Internet.
too many free-riders, an increasing number of the well- In P2P networks, free-riding is a well-known prob-
behaving peers may not achieve high enough download lem [1, 9]. A free-rider in a P2P network is a peer who con-
speeds to maintain an acceptable service. In this paper we sumes more resources than it contributes, and more specif-
propose Give-to-Get, a P2P VoD algorithm which discour- ically, in the case of VoD, it is a peer who downloads data
ages free-riding by letting peers favour uploading to other but uploads little or no data in return. The burden of upload-
peers who have proven to be good uploaders. As a conse- ing is on the altruistic peers, who may be too few in number
quence, free-riders are only tolerated as long as there is to provide all peers with an acceptable quality of service. In
spare capacity in the system. Our simulations show that both live streaming and VoD, peers require a minimal down-
even if 20% of the peers are free-riders, Give-to-Get con- load speed to sustain playback, and so free-riding is espe-
tinues to provide good performance to the well-behaving cially harmful as the altruistic peers alone may not be able
peers. Also, they show that Give-to-Get performs best if the to provide all the peers with sufficient download speeds.
video that is distributed is short. Solutions to solve the free-riding problem have been pro-
posed for off-line downloading [3] and live streaming [6, 7].
However, for P2P VoD, no solution yet exists which takes
1 Introduction free-riding into consideration. Therefore, in this paper we
propose an algorithm called “Give-to-Get” for VoD in P2P
Multimedia content such as movies and TV programs systems, which assumes videos to be split up into chunks of
can be downloaded and viewed from remote servers using a fixed size. In Give-to-Get, peers have to upload (give) the
one of three methods. First, with off-line downloading, a chunks received from other peers in order to get additional
pre-recorded file is transferred completely to the user before chunks from those peers. By preferring to serve good for-
he starts watching it. Secondly, with live streaming, the user warders, free-riders are excluded in favour of well-behaving
immediately watches the content while it is being broad- peers. Free-riders will thus be able to obtain video data only
cast to him. The third method, which holds the middle be- if there is spare capacity in the system.
tween off-line downloading and live streaming and which is Apart from the problems introduced by free-riders, a P2P
the one we will focus on, is Video-on-Demand (VoD). With VoD system also has to take care that the chunks needed for
VoD, pre-recorded content is streamed to the user, who can playback in the immediate future are present. For this pur-

pose, we define a chunk prebuffering policy for download-
ing the first chunks of a file before playback starts, as well
an ordering of the requests for the downloads of the other 3 Problem Description
chunks. We will use the required prebuffering time and the
incurred chunk loss rate as the metrics to evaluate the per- The problem we address in this paper is the design of a
formance of Give-to-Get, which we will report separately P2P VoD algorithm which discourages free-riding. In this
for the free-riders and for the well-behaving peers. section, we will describe how a P2P VoD system operates
The remainder of this paper is organized as follows. In in our setting in general.
Section 2, we discuss related work. In Section 3, we further Similarly to BitTorrent [3], we assume that the video file
specify the problem we address, followed by a description to be streamed is split up into chunks of equal size, and that
of the Give-to-Get algorithm in Section 4. Next, we present every peer interested in watching the stream tries to obtain
our experiments and their results in Section 5. Finally, we all chunks. Due to the similarities with BitTorrent, we will
draw conclusions and discuss future work in Section 6. use its terminology to describe both our problem and our
proposed solution.
A P2P VoD system consists of peers which are down-
2 Related Work
loading the video (leechers) and of peers which have fin-
ished downloading, and upload for free (seeders). The sys-
An early algorithm for distributed VoD is Chaining [10], tem starts with at least one seeder. We assume that a peer
in which the video data is distributed over a chain of is able to obtain the addresses of a number of random other
peers. Such a solution works well for a controlled environ- peers, and that connections are possible between any pair of
ment, but is less suitable for P2P networks. In P2Cast [5], peers.
P2VoD [4] and OBN [8], peers are grouped according to To provide all leechers with the video data in a P2P
similar arrival times. The groups forward the stream within fashion, a multicast tree has to be used for every chunk of
the group or between groups, and turn to the source if no el- the video. While in traditional application-level multicast-
igible supplier can be found. In all three algorithms, a peer ing, the same multicast tree is created for all chunks and
can decide how many children it will adopt, making the al- is changed only when peers arrive or depart, we allow the
gorithms vulnerable to free-riding. multicast trees of different chunks to be different based on
Our Give-to-Get algorithm borrows the idea of bartering the dynamic behavior of the peers. These multicast trees are
for chunks of a file from BitTorrent [3], which is a very pop- not created ahead of time, but rather come into being while
ular P2P system for off-line downloading. In BitTorrent, the chunks are being propagated in the system. An important
content is divided into equally sized chunks which are ex- requirement is that we want our solution to be resilient to
changed by peers on a tit-for-tat basis. In deployed BitTor- free-riding.
rent networks, the observed amount of free-riding is low [2]. A peer typically behaves in the following manner: It
However, a recent study [9] has shown that with a specially joins the system as a leecher and contacts other peers in
designed client, free-riding in BitTorrent is possible without order to download chunks of a video. After a prebuffering
a significant performance impact for the free-riding peer. Of period, the peer starts playback, and after the peer has fin-
course, the performance of the network as a whole suffers if ished downloading, it will remain a seeder until it departs. A
too many peers free-ride. In BiToS [11], the BitTorrent pro- peer departs when the video has finished playing, or earlier
tocol is adapted for VoD. Peers focus most of their tit-for- if the user aborts playback.
tat chunk trading on their high-priority set, which consists We assume the algorithm to be designed for P2P VoD to
of the chunks which are due for playback soon. Because be video-codec agnostic, and so we will consider the video
the high-priority sets of different peers do not necessarily to be a constant bit-rate stream with unknown boundary po-
overlap due to differences in their arrival times, tit-for-tat sitions between the consecutive frames.
is not always possible. Also, in [11], the prebuffering time
required by peers is not studied, making it hard to judge the
obtained quality of service. 4 Give-to-Get
BAR Gossip [7] and EquiCast [6] are both solutions for
live streaming which combat free-riding, but they are not In this section, we will explain Give-to-Get, our P2P VoD
aimed at VoD and they require trusted nodes to police the algorithm which discourages free-riding. First, we will de-
network and a central server to monitor and maintain the scribe how a peer maintains information about other peers
network, respectively. in the system in its so-called neighbour list. Then, the way
the video pieces are forwarded from peer to peer is dis-
cussed. Next, we show in which order video pieces are

transferred between peers. Finally, we will discuss when a Algorithm 1 Unchoking algorithm (optimistic unchoking
peer decides it can start playing the video. not included)
choke(all neighbours)
4.1 Neighbour Management N ⇐ all interested neighbours
sort N on forwarding rank
The system we consider consists of peers which are in- for i = 1 to min(|N |, 3) do
terested in receiving the video stream (leechers) and peers unchoke(N [i])
which have obtained the complete video stream and are end for
for i = 4 to min(|N |, 4 + ǫ) do
willing to share it for free (seeders). We assume a peer is i−1
b ⇐ k=1 (upload speed toN [k])
able to obtain addresses of other peers uniformly at random.
if b > UPLINK ∗ 0.9 then
Mechanisms to implement this could be centralised, with a break
server keeping track of who is in the network, or decen- end if
tralised, for example, by using epidemic protocols or DHT unchoke(N [i])
rings. We view this peer discovery problem as orthogonal to end for
our work, and so beyond the scope of this paper.
From the moment a peer joins the system, it will obtain
and maintain a list of 10 neighbours in its neighbour list. the uplink, more neighbours are unchoked until the uplink
When no 10 neighbours can be contacted, the peer periodi- bandwidth necessary to serve the unchoked peers reaches
cally tries to discover new neighbours. To maintain a useful 90% of p’s uplink. At most ǫ neighbours are unchoked this
set of neighbours, a peer disconnects from any neighbour if way to avoid serving too many neighbours at once, which
no video data has been sent in either direction over the last would decrease the performance of the individual connec-
30 seconds. Also, once a peer becomes a seeder, it discon- tions. The optimal value for ǫ likely depends on the avail-
nects from other seeders. able bandwidth and latency of p’s network connection. In
our experiments, we use ǫ = 2.
4.2 Chunk Distribution To search for better children, p round-robins over the
rest of the neighbours and optimistically unchokes a dif-
In this section we will present the way peers forward ferent one of them every 2δ seconds. If the optimistically
chunks of a video file to each other. We first discuss the unchoked peer proves to be a good forwarder and ends up
general mechanism, and subsequently explain the way peers at the top, it will be automatically kept unchoked. New con-
rank their neighbours in this mechanism. nections are inserted uniformly at random in the optimistic
unchoke list. The duration of 2δ seconds is enough for a
4.2.1 Forwarding Chunks neighbour to prove its good behaviour.
By only uploading chunks to the best forwarders, its
The video data is split up into chunks of equal size. As Give- neighbours are encouraged to forward the data as much as
to-Get is codec agnostic, the chunk boundaries do not nec- possible. While peers are not obliged to forward their data,
essarily coincide with frame boundaries. Peers obtain the they run the danger of not being able to receive video data
chunks by requesting them from their neighbours. A peer once other peers start to compete for it. This results in a sys-
keeps its neighbours informed about the chunks it has, and tem where free-riders are tolerated only if there is sufficient
decides which of its neighbours is allowed to make requests. bandwidth left to serve them.
A neighbour which is allowed to make requests is unchoked.
When a chunk is requested, the peer appends it to the send
4.2.2 Forwarding Rank
queue for that connection. Chunks are uploaded using sub-
chunks of 1 Kbyte to avoid delays in the delivery of control A peer p ranks its neighbours based on the number of
messages, which are sent with a higher priority. chunks they have forwarded during the last δ seconds. Our
Every δ seconds, a peer decides which neighbours are ranking procedure consists of two steps:
unchoked based on information gathered over the last δ
seconds. Algorithm 1 shows the pseudocode of how these 1. First, the neighbours are sorted according to the de-
decisions are made. A peer p ranks its neighbours accord- creasing numbers of chunks they have forwarded to
ing to their forwarding ranks, which represent how well a other peers, counting only the chunks they originally
neighbour is forwarding chunks. The calculation of the for- received from p.
warding rank is explained in the next section. Peer p un- 2. If two neighbours have an equal score in the first step,
chokes the best three forwarders. Since peers are judged by they are sorted according to the decreasing total num-
the amount of data they forward, it is beneficial to make effi- ber of chunks they have forwarded to other peers.
cient use of the available upload bandwidth. To help saturate

Either step alone does not suffice as a ranking mechanism.
If neighbours are ranked solely based on the total number
of chunks they upload, good uploaders will be unchoked by r o u n d t r i p

all their neighbours, which causes only the best uploaders t i m e t o q

to receive data and the other peers to starve. On the other
hand, if neighbours are ranked solely based on the number H I G H M I D

of chunks they receive from p and forward to others, peers
O W P R I O

P R I O P R I O L

which are optimistically unchoked by p have a hard time
becoming one of the top ranked forwarders. An optimisti- h

4
h

cally unchoked peer q would have to receive chunks from p V V

and hope for q’s neighbours to request exactly those chunks
i d e o m ( p l a y b a c k i d e o

s t a r t p o s i t i o n ) e n d

often enough. The probability that q replaces the other top
forwarders ranked by p is too low.
Peer p has to know which chunks were forwarded by its
neighbours to others. To obtain this information, it cannot
ask its neighbours directly, as they could make false claims. Figure 1. The high-, mid- and low-priority sets
Instead, p asks its grandchildren for the behaviour of its in relation to the playback position and the
children. The neighbours of p keep p updated about the average round-trip time to p’s neighbours.
peers they are forwarding to. Peer p contacts these grand-
children, and asks them which chunks they received from
p’s neighbours. This allows p to determine both the forward-
ing rates of its neighbours as well as the numbers of chunks enough chunks which are wanted by other peers. The for-
they forwarded which were originally provided by p. mer favours downloading chunks in-order, the latter favours
downloading rare chunks first. To balance between these
4.3 Chunk Picking two requirements, Give-to-Get employs a hybrid solution
by prioritizing the chunks that have yet to be played back.
A peer obtains chunks by issuing a request for each Let m be the minimum chunk number peer p wants from a
chunk to other peers. A peer thus has to decide in which neighbour q. Peer p will request chunk i on the first match
order it will request the chunks it wants to download; this in the following list of sets of chunks (see Figure 1):
is called chunk picking. When a peer p is allowed by one of
• High priority: m ≤ i m + h. If p has already started
its neighbours to make requests to it, it will always do so if
playback, it will pick the lowest such i, otherwise, it
the neighbour has a chunk p wants. We associate with every
will pick i rarest first.
chunk and every peer a deadline, which is the latest point
• Mid priority: m + h ≤ i m + (µ + 1)h. Peer p will
in time the chunk has to be present at the peer for playback.
choose such an i rarest first.
As long as p has not yet started playback, the deadline of
• Low priority: m + (µ + 1)h ≤ i. Peer p will choose
every chunk at p is infinite. Peer p wants chunk i from a
such an i rarest first.
neighbour q if the following conditions are met:
• q has chunk i, In these definitions, h and µ are parameters which dictate
• p does not have chunk i and has not previously re- the amount of clustering of chunk requests in the part of
quested it, the video yet to be played back. A peer picks rarest-first
• It is likely that chunk i arrives at p before its deadline. based on the availability of chunks at its neighbours. Among
chunks of equal rarity, i is chosen uniformly at random.
Because peers keep their neighbours informed about the
This ordering ensures in-order downloading in the high-
chunks they have, the first two rules are easy to check. To
priority set (when chunk deadlines are due). The mid-
estimate whether a chunk will arrive on time, p keeps track
priority set downloads the future high-priority set in ad-
of the response time of requests. This response time is in-
vance using rarest-first. This lowers the probability of hav-
fluenced by the link delay between p and q as well as the
ing to do in-order downloading later on. The low-priority set
amount of traffic from p and q to other peers. Peers can sub-
will download the rest of the chunks using rarest-first both
mit multiple requests in parallel in order to fully utilise the
to collect chunks which will be forwarded often because
links with their neighbours.
they are wanted by many and to increase the availability of
When deciding the order in which chunks are picked,
the rarest chunks.
two things have to be kept in mind. First, it is necessary
to provide the chunks in-order to the video player. Sec-
ondly, to achieve a good upload rate, it is necessary to obtain

4.4 Video Playback capacity chosen uniformly at random between 0.5 and 1.0
Mbit/s. The uplink capacity of a peer is evenly shared be-
The primary objective of a peer is to view the offered tween the connections and is considered to be the bottleneck
video clip. For a peer to view a video clip in a VoD fashion, between any pair of peers. The round-trip times between
two conditions must be met to provide a good quality of pairs of peers vary between 100 ms and 300 ms. A peer re-
service. First, the start-up delay must be small to provide the considers the behaviour of its neighbours every δ = 10 sec-
user with a streaming experience. Second, the chunk loss onds, which is a balance between keeping the overhead low
must be low to provide good playback quality. If either of and allowing neighbour behaviour changes (including free-
these criteria is not met, it is likely the user was better off riders) to be detected. The high-priority set size h is defined
downloading the whole clip before viewing it. to be the equivalent of 10 seconds of video. The mid priority
We will assume that once prebuffering is finished and set size is µ = 4 times the high priority set size.
playback is started, the video will not be paused or slowed A 5-minute video of 0.5 Mbit/s is cut up into 16 Kbyte
down. In general, the amount of prebuffering is a trade- chunks (i.e., 4 chunks per second on average) and is being
off between having a short waiting period and having low distributed from the initial seeder with a 2 Mbit/s uplink.
chunk loss during playback. This makes the prebuffering We will use the required prebuffering time and the chunk
period an important metric in VoD. loss as the metrics to assess the performance of Give-to-
In Give-to-Get, we decide on the prebuffering time as Get. We will present separate results for the free-riders and
follows. First, the peer waits until it has the first h chunks the well-behaving peers.
(the first high-priority set) available to prevent immedi-
ate chunk loss. Then, it waits until the remaining down- 5.2 Default Behaviour
load time is less than the duration of the video plus 20%
overhead. This overhead allows for short or small drops in In the first experiment, peers depart only when their play-
download rate later on, and will also create an increasing back is finished, and there are no free-riders. We do three
buffer when the download rate does not drop. runs, letting peers arrive at an average rate of 0.2/s, 1.0/s,
In order to keep the prebuffering time reasonable, the av- and 10.0/s, respectively. Figures 2, 3 and 4 show the results
erage upload speed of a peer in the system should thus be of a typical run.
at least the video bitrate plus 20% overhead. If there is less In Figure 2(a), 3(a) and 4(a), the percentage of chunk
upload capacity in the system, peers both get a hard time loss is shown over time, as well as the number of playing
obtaining all chunks and are forced to prebuffer longer to peers and the number of seeders in the system. As long as
ensure the download will be finished before the playback is. the initial seed is the only seed in the system, peers expe-
rience some chunk loss. Once peers are done downloading
5 Experiments the video, they can seed it to others and after a short period
of time, no peer experiences any chunk loss at all. A com-
In this section we will present our experimental setup parison the graphs of the three arrival rates reveals that per-
as well as the experiments for assessing the performance formance is better at high and low arrival rates compared to
of the Give-to-Get algorithm. We will present the results of the performance at 1.0/s. At low arrival rates, the maximum
four experiments. In the first experiment, we measure the number of peers that can be playing at the same time is low.
default behaviour with well-behaving peers. In the second In a small system, the initial seed has a relatively high im-
experiment, we measure the performance when a part of the pact on the performance. When the arrival rate is high, peers
system consists of free-riders. Next, we let peers depart be- have neighbours which are interested in the same chunks
fore they have finished watching the video. In the last ex- and thus overlapping mid priority sets. As a result, the num-
periment, we increase the movie length. ber of neighbours which have interesting pieces increases
for all peers. In contrast, if two peers do not have an over-
5.1 Experimental Setup lapping mid priority set, they have a highly biased interest
in each others’ pieces. The peer with the lower playback
position is likely to be interested in pieces of the peer with
Our experiments were performed using a discrete-event
the higher playback position, but not the other way around.
simulator, emulating a network of 500 peers. Each simula-
Further experiments have shown that for the parameters we
tion starts with one initial seeder, and the rest of the peers
use in this paper, the arrival rate of 1.0/s produces the worst
arrive according to a Poisson process. Unless stated other-
performance.
wise, peers arrive at a rate of 1.0/s, and depart when play-
Figures 2(b), 3(b) and 4(b), show the cumulative distri-
back is finished. When a peer is done downloading the video
bution of the required prebuffering time. Recall that peers
stream, it will therefore become a seeder until the playback
start playback as soon as they have obtained the first 10
is finished and the peer departs. Every peer has an uplink

number of peers (cumulative)
20 80 500
70
400

number of peers
chunk loss (%) 15 60
chunk loss (g2g) 50 300
number of peers (g2g)
10 40
chunk loss (bitos)
number of peers (bitos) 30 200
5 20
100 g2g
10
bitos
0 0 0
0 100 200 300 400 500 600 700 800 0 10 20 30 40 50 60 70
time (s) time (s)
(a) The average chunk loss and the number of playing peers and seeders. (b) The cumulative distribution of the pre-
buffering time.

Figure 2. A sample run with peers arriving at a rate of 0.2 per second.

20 350 500
chunk loss (g2g)
number of peers (g2g) 300
400

number of peers
15 chunk loss (bitos)
chunk loss (%)

250
number of peers (bitos)
200 300
10
150 200
5 100
100 g2g
50
bitos
0 0 0
0 100 200 300 400 500 600 700 800 0 10 20 30 40 50 60 70
time (s) time (s)
buffering time.


20 500 500
chunk loss (g2g) 450
number of peers (g2g) 400 400
number of peers

15 chunk loss (bitos)
chunk loss (%)

number of peers (bitos) 350
300 300
10 250
200 200
150
5
100 100 g2g
50 bitos
0 0 0
0 100 200 300 400 500 600 700 800 0 10 20 30 40 50 60 70
time (s) time (s)
buffering time.


seconds of video, and the download speed is 1.2 times the 1.0/s. In that case, Figure 3(b) shows that half of them can
video playback speed. The measured prebuffering times re- start playback within 14 seconds, and 90% of them can start
flect this, as all peers require at least 10 seconds before they playback within 41 seconds. We present these numbers to
can start playback. The arrival rate influences the prebuffer- allow a comparison with the other experiments.
ing time as can be seen by comparing the individual graphs.
At high arrival rates, there are many peers in the system be- 5.3 Free-riders
fore the first few peers have obtained the initial 10 seconds
of video. Due to the high competition, it takes longer for all In the second experiment, we add free-riders to the sys-
peers to obtain these pieces, obtain enough download speed tem by having 20% of the peers not upload anything to oth-
and start playback. ers. The results of this experiment are shown for the well-
The rest of the experiments assume an arrival rate of behaving peers in Figures 5(a) and 5(b). The well-behaving

50 300 400
250 350

number of peers
40
chunk loss (%)

200 300
30 250
150
20 200
100
150
10 50
100
0 0 50
0 100 200 300 400 500 600 700 800
0
time (s) 0 10 20 30 40 50 60 70
average chunk loss number of peers time (s)
(a) The average chunk loss and the number of playing peers and seeders. (b) The cumulative distribution of the prebuffering time.

Figure 5. The performance of the well-behaving peers if 20% of the peers free-ride.

50 90 100
80

number of peers
40
chunk loss (%)

70 80
60
30 50 60
20 40
30
40
10 20
10
0 0 20
0 100 200 300 400 500 600 700 800
0
time (s) 0 10 20 30 40 50 60 70

Figure 6. The performance of the free-riders if 20% of the peers free-ride.

peers are affected by the presence of the free-riders, mostly 5.4 Early Departures
by experiencing a bit more chunk loss and but also by re-
quiring a bit more prebuffering time. A slight performance In the third experiment, we assess the impact of peers de-
degradation is to be expected, as well-behaving peers occa- parting before they finish playback. Peers that depart early
sionally upload to free-riders as part of the optimistic un- have a lower probability of having downloaded, and thus
choking process. Any chunk sent to a free-rider is not sent forwarded, the higher-numbered chunks. Also, they have a
to another well-behaving peer instead. Half of the peers re- lower probability of seeding. Thus, the availability of the
quire at most 30 seconds of prebuffering, and 90% of them highest-numbered chunks and seeders in general decreases.
require at most 53 seconds, which is substantially more than We let half of these peers depart during playback, at a
in a system without free-riders, as shown in Figure 3(b). point chosen uniformly at random. In Figure 7(a), we show
For the free-riders, the performance is much worse as can the chunk loss results, and in Figure 7(b), we show the pre-
be seen in Figures 6(a) and 6(b). When peers are still arriv- buffering times required by the peers. The chunk loss is cer-
ing and no seeders are present, the leechers have to com- tainly higher than in the previous tests, but is still within
pete and the free-riders suffer from a high chunk loss. Once an acceptable range. Half of the peers start playback within
seeders start to become available, bandwidth becomes more 19 seconds, and 90% of them start playback within 41 sec-
abundant, and well-behaving peers are sufficiently served, onds, which is slightly worse than when peers do not depart
the free-riders as well as the well behaving peers suffer lit- before playback is finished.
tle to no chunk loss. Because the free-riders have to wait for
bandwidth to become available, they either start early and 5.5 Increased Video Length
suffer a high chunk loss, or they have a long prebuffering
time. In the shown run, half of the free-riders required up to In the last experiment, we measure the effect of increas-
52 seconds of prebuffering time, but 90% required at most ing the video length, as well as the effect of increasing the
259 seconds. µ variable, which controls the size of the mid priority set.
The results for videos with a length of 5, 10 and 30 min-
utes are shown in Figure 8. For each video length, the figure
shows the median amount of prebuffering required as well

20 250 500

number of peers
200
chunk loss (%)

15 400
150
10 300
100
5 200
50

0 0 100
0 100 200 300 400 500 600 700 800
0
time (s) 0 10 20 30 40 50 60 70

Figure 7. A sample run with half of the peers departing before playback is ﬁnished.

70 6 Conclusions and Future Work
prebuffering median (s)

60
50
We have presented Give-to-Get, a P2P video-on-demand
40
algorithm which discourages free-riding. In Give-to-Get,
30
20
peers are encouraged to upload data to neighbours which
5 min
10 10 min prove to be the best forwarders. This policy hurts free-riders
30 min
0 any time their neighbours have the opportunity to forward
average chunk loss (%)

7 to well-behaving peers instead. When resources are abun-
6 5 min
10 min dant, such as when there are many seeders, free-riders can
5 30 min
4 still join and watch the video at acceptable quality. This al-
3 lows users with low upload capacity but enough download
2 capacity such as ADSL users to join the system as long as
1
0 it can support them.
0 4 8 12 16 20 24 Give-to-Get also has its limitations. First of all, it does
mu
not scale with the length of the video. Longer movies mean
Figure 8. Average chunk loss and median a higher chunk loss and so a lower perceived quality. Sec-
prebuffering times against the size of the ondly, the algorithm relies on second-hand information—
mid-priority set for several video lengths. peers query others about the behaviour of their neighbours.
If a user can easily generate multiple identities in the sys-
tem, he can report about his own behaviour, which would
make their free-riding go unnoticed. As future work, we
as the average chunk loss for various values of µ. Both the plan to investigate whether these limitations can be re-
amount of chunk loss and the amount of required prebuffer- moved, and whether the performance of Give-to-Get can be
ing increases with the video length for all the values tested. improved.
By changing the size of the mid priority set, the amount
of chunk loss can be lowered but this results in a longer
prebuffering time. Whether this is an acceptable trade-off
References
depends on the video codec as well as the video content.
[1] E. Adar and B. Huberman. Freeriding on Gnutella. First
Like the previous experiments, the chunk loss in all runs
Monday, 5(10), 2000.
was biased towards the beginning, when no seeders except
the original one are available. The average chunk loss ob- [2] N. Andrade, M. Mowbray, A. Lima, G. Wagner, and M. Ri-
served during that period is thus several times higher than peanu. Inﬂuences on Cooperation in BitTorrent Communi-
ties. In Proc. of ACM SIGCOMM, pages 111–115, 2005.
the average over the full run. Compare for instance Figure
3(a), in which the movie length is 5 minutes and µ = 4, [3] B. Cohen. BitTorrent.
against the respective datapoint in Figure 8. The average http://www.bittorrent.com/.
chunk loss over the whole run is 0.5%, although most of [4] T. Do, K. Hua, and M. Tantaoui. P2VoD: Providing Fault
the loss occurs as an average chunk loss of around 3% for a Tolerant Video-on-Demand Streaming in Peer-to-Peer Envi-
period of 200 seconds. ronment. In Proc. of the IEEE Intl. Conf. on Communica-
tions, volume 3, pages 1467–1472, 2004.

[5] Y. Guo, K. Suh, J. Kurose, and D. Towsley. P2Cast: P2P
Patching Scheme for VoD Services. In Proc. of the 12th
World Wide Web Conference, pages 301–309, 2003.
[6] I. Keidar, R. Melamed, and A. Orda. EquiCast: Scalable
Multicast with Selﬁsh Users. In Proc. of the 25th ACM Sym-
posium on Principles of Distributed Computing, pages 63–
71, 2006.
[7] H. Li, A. Clement, E. Wong, J. Napper, I. Roy, L. Alvisi, and
M. Dahlin. BAR Gossip. In Proc. of the 7th USENIX Op-
erating Systems Design and Implementation (OSDI), pages
191–206, 2006.
[8] C. Liao, W. Sun, C. King, and H. Hsiao. OBN: Peering
Finding Suppliers in P2P On-demand Streaming Systems.
In Proc. of the 12th Intl. Conf. on Parallel and Distributed
Systems, volume 1, pages 8–15, 2006.
[9] T. Locher, P. Moor, S. Schmid, and R. Wattenhofer. Free
Riding in BitTorrent is Cheap. In Proc. of the 5th Workshop
on Hot Topics in Networks, 2006.
[10] S. Sheu, K. Hua, and W. Tavanapong. Chaining: A Gener-
alizing Batching Technique for Video-On-Demand Systems.
In Proc. of the Int. Conf. on Multimedia Computing and Sys-
tems, pages 110–117, 1997.
[11] A. Vlavianos, M. Iliofotou, and M. Faloutsos. BiToS: En-
hancing BitTorrent for Supporting Streaming Applications.
In IEEE Global Internet Symposium, 2006.

Give to-get algorithm-for_p2_p_video_on_demand

More Related Content

Similar to Give to-get algorithm-for_p2_p_video_on_demand (20)

Give to-get algorithm-for_p2_p_video_on_demand