Computer Science Technical Report Archive

USC Computer Science Technical Reports, no. 924 (2012)

(USC DC Other)

USC Computer Science Technical Reports, no. 924 (2012)

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content P2P Streaming: a Study on the Use of Advertisements as
Incentives
Bo-Chun Wang
¤
, Alix L.H. Chow
y
, Leana Golubchik
¤
¤
Department of Computer Science, University of Southern California
y
Nokia Research Center, Beijing, China
{bochunwa@usc.edu, alix.chow@nokia.com, leana@usc.edu}
ABSTRACT
P2P streaming systems, such as PPLive, PPStream, and TVUPlayer,
have become popular services with the widespread deployment of
broadband networks. However, P2P streaming systems still face
free-riding problems, similar to those that have been observed in
P2P file sharing systems. Thus, one important problem in provid-
ing streaming services is that of providing appropriate incentives
for peers to contribute their upload capacity. To this end, we pro-
pose the use of advertisements as an incentive for peers to con-
tribute upload capacity. In the proposed framework, peers enjoy
the same quality of streamed media, with the difference in qual-
ity of service being achieved through different amounts of adver-
tisements viewed, based on the resource contributions to the sys-
tem. An extensive simulation-based study is performed to evalu-
ate the proposed approach. The results demonstrate that our ap-
proach provides appropriate incentives for peers to contribute their
resources.
Categories and Subject Descriptors
C.2 [COMPUTER-COMMUNICATION NETWORKS]: Distributed
networks
General Terms
Design; Performance
Keywords
P2P streaming systems; incentive; advertisement; token-based;
1. INTRODUCTION
The use of Peer-to-Peer (P2P) technology has led to efficient dis-
tribution of content over large scale networks. For instance, Bit-
Torrent [1] is one of the most successful file sharing applications
in use today. In the past few years, P2P-based streaming has
become another popular service, with the widespread deployment
of broadband networks. P2P-based approaches to streaming have
become popular, as compared to traditional client-server-based ap-
proached, due to the following advantages: low cost, scalability,
and ease of deployment. There are already several P2P stream-
ing applications deployed on the Internet, such as PPLive [3], PP-
Stream [5], and TVUPlayer [6]. Moreover, a number of efforts
have focused on measurement and analysis of such P2P streaming
systems [9, 12, 27].
However, P2P streaming systems still suffer from free-riding prob-
lems, i.e., similarly to the free-riding problems observed in P2P file
sharing systems. For example, X. Hei et al [9] provide four mea-
surement results of PPlive (two from university campuses and two
from residential locations). Peers in one of the residential locations
do almost no uploads. These peers may be considered as free-
riders. Moreover, they have also shown that deployed streaming
systems’ performance depends on peers with high upload capaci-
ties, given that there is significant upload bandwidth heterogeneity
on the Internet. In order to provide satisfactory performance, the
quantity of peers with high upload capacities in streaming systems
should be sufficiently high [11]. Therefore, the problem of how
to provide appropriate incentives for peers to contribute their up-
load capacity to the system is an important one in the context of
P2P-based streaming systems. Although some approaches exist for
addressing this problem in the context of P2P file sharing systems,
providing incentives in streaming systems can be a more complex
problem. For instance, such approaches in file-sharing systems typ-
ically provide a reduction in file downloading time as an incentive.
However, in streaming systems, a peer’s quality of service depends
on video quality (e.g., smoothness of video delivery), rather than on
how fast the entire stream (e.g., video) can be downloaded. Hence,
there is a need for re-considering the problem of providing appro-
priate incentives for peers to contribute resources in the context of
P2P streaming systems.
To address the incentives problem in streaming systems, several
techniques have been proposed in the literature, such as [10, 14–
16, 18, 20, 21, 23, 25]. Most of these works use improved video
quality as an incentive, achieved through layered coding-based or
MDC-based techniques [14, 15, 17]. Briefly, the basic idea here
is that peers will have better video quality when they upload more
data. (A more detailed description is given in Section 5.)
In this paper we consider an alternative direction for providing in-
centives in P2P streaming systems, namely that of using the amount
of advertisements viewed as an incentive to contribute more re-
sources, as described next. Our approach is orthogonal to (and can
be combined with) previous efforts whose goals are to provide bet-
ter video quality (as detailed below).
Advertisement supported service has become a popular business
model. Many popular systems ask users to watch advertisements
before users start to watch videos (e.g., Youtube [7] and Hulu [2]).
Since advertisements could provide additional revenue for a service
provider in a P2P streaming system, such providers could include
advertisements in the distributed content (e.g., as is currently done
on television). Since all peers (whether high or low capacity) are
concerned with video quality (e.g., in the form of smoothness in
data delivery), controlling the amount of advertisements viewed by
a peer would be another approach to providing incentives for peers
to contribute resources in a P2P streaming system. (In a sense, our
system is analogous to having broadcast (free) TV and paid TV
channels, e.g., such as HBO. For instance, a user can view movies
on a paid TV channel without advertisements, or the user can view
the same movie on a free TV channel with advertisements. In our
case, the “payment" we consider is the peers’ resource contribu-
tion.) Briefly, in our proposed system, peers who contribute more
upload capacity view fewer advertisements than peers who con-
tribute less upload resources. Thus, unlike in layered coding/MDC
based schemes, low capacity peers can still enjoy good video qual-
ity but with more advertisements than higher capacity peers. In this
paper, we focus on the architecture of such a system and its evalua-
tion, including issues such as tracking of peers’ contributions while
preventing malicious behavior as well as efficient distribution of
advertisements.
One important challenge in such a system is accounting for peers’
contributions, on which the system can in turn base the compu-
tation of the amount of advertisements a peer should view. One
possible approach is to allow peers to report their own contribu-
tions. However, since malicious peers may report more than their
actual contribution, such a method is open to abuse by free-riders
or malicious peers. Therefore, in this paper, we design token-based
schemes to address the problem of determining how much contri-
bution each peer is making. Token-based schemes have been used
in P2P file sharing systems [13, 19, 26, 29] as well as other sys-
tems. In [13, 26, 29], token-based schemes are considered as a
form of credit systems or micro-payment systems, where peers can
exchange tokens, as virtual currency, to receive resources or ser-
vices, and a service provider can charge based on the amount of
tokens attained. In [19], token-based schemes are used for two in-
centive purposes, reputation and payment. Peers should maintain
high reputation, otherwise, other peers may refuse to interact with
them. In addition, peers “pay" with tokens for downloading con-
tent and receive tokens for uploading content to other peers. Thus,
a free-rider cannot download data due to lack of tokens. In this
paper, we adopt the idea of using tokens as payment in designing
our system. Our main purpose in utilizing tokens is in creating a
mechanism for accounting for peers’ contributions. Unlike other
efforts where tokens are used to limit downloading or support rep-
utation, we use tokens to determine the amount of advertisements
peers should view. (The details of our system architecture are given
below.)
Briefly, in our token-based schemes, a peer “pays" with tokens
when downloading steaming content. A peer receives tokens, when
contributing its upload capacity for streaming data to other peers.
Then, the amount of advertisements shown to each peer is based
on the number of tokens each peer possesses. The advantage of
this token-based approach is that the use of tokens can prevent ma-
licious peers from reporting incorrect contributions. In addition,
we insure that malicious peers do not “fake" tokens (i.e., generate
tokens on their own) through the use of cryptographic-based signa-
tures.
Our contributions in this paper can be summarized as follows.
² We consider the use of advertisements as an incentive in P2P
streaming systems for peers to contribute upload resources
and propose a corresponding P2P-based streaming system ar-
chitecture. Since, advertisement supported services are likely
to become more and more popular, our approach could pro-
vide peers an important incentive for contributing their up-
load capacity. In Section 3, our simulation-based study demon-
strates the utility of this approach - for instance, when peers
increase their uploading rate, the system provides reduced
amount of advertisement based on true contributions. More-
over, we also focus on efficient distribution of advertisements
in Section 3.1.
² We propose a token-based framework as an approach to ad-
dress the problem of accounting for peers’ contributions so
as to determine the amount of advertisements peers should
view (see Section 2). We propose three token-based schemes
and explore their characteristics, such as overhead, reliabil-
ity, management, and resilience to malicious behavior (see
discussion in Section 4). In Section 3, we present our simulation-
based study that illustrates several useful characteristics of
our schemes. These include, a demonstration of how to re-
duce overhead needed for implementing such token-based
schemes in Section 3.2 and what are the trade-offs between
overhead reduction and accuracy in Section 3.3. Our results
provide system developers with insight into efficient devel-
opment of P2P-based streaming systems that utilize adver-
tisements as incentives for resource contribution.
2. THE PROPOSED SYSTEM
In this section, we present the proposed system which uses adver-
tisements as incentives in a P2P streaming system. In this system,
peers view different amounts of advertisements, based on their re-
source contributions to the system. An advertisement in our system
can be any object - e.g., it can be a video clip, flash animation,
streamed media, and so on. In general, the type of advertisement
is determined by the content provider. For ease of exposition, in
this paper we focus on one type of advertisement, namely streamed
media.
The main challenge in our system is that of determining peers’ true
resource contributions. One possible approach is to allow peers to
report their own contributions. However, this method does not pre-
vent malicious peers from reporting incorrect contributions. That
is, in order for advertisement-based incentives to produce a desired
effect, we need to construct a system where peers’ contributions
can be determined reasonably accurately (at least relative to each
other).
To this end, we design token-based schemes. Our token-based
schemes include three functions:
² token generation: How are tokens generated?
² token exchange: How do peers exchange tokens in order to
download streamed content?
² contribution calculation: How are peers’ contributions calcu-
lated, and how is the amount of advertisements peers have to
view determined?
Streaming Server Token Server
Streamed media
Tokens
Advertisement
Peer with high
uploading rate
Peer with low
uploading rate
Figure 1: System Architecture
Since token generation and contribution calculation could be done
at the peer-side or the server-side, we consider different combina-
tions and propose the following schemes in this paper:
² Token generation at Peer-side and Contribution calculation
at Peer-side (TPCP)
² Token generation at Server-side and Contribution calculation
at Peer-side (TSCP)
² Token generation at Peer-side and Contribution calculation
at Server-side (TPCS)
Note that, using different token-based schemes does not affect the
quantity of peers’ contributions. The motivation for considering
different schemes is to explore overhead and reliability characteris-
tics of each schemes. The information can help system developers
choose appropriate schemes by considering the trade-offs between
overhead and reliability. Note that, we do not consider token gen-
eration at the server-side and contribution calculation at the server-
side because this scheme is completely centralized and is not ap-
propriate for P2P systems.
Fig. 1 illustrates our system architecture. The system consists of a
streaming server and peers. In the TSCP and TPCS schemes, the
system also includes a token server. The streaming server and the
token server are managed by the service provider. The streaming
server is responsible for generating the streamed content as well as
the advertisements, while the token server is responsible for gen-
erating tokens or computing peers’ resource contributions. The
sources of advertisements could be the service provider or spon-
sors.
The streaming format considered in the remainder of the paper is
single-layer video with substreams, as in [16]. The basic idea of
substreams is to encode a video stream into several substreams,
each having the same video rate, i.e., the streaming server encodes
streamed content into k substreams and distributes k substreams
through the P2P system. The main advantage of a system using
substreams is that it can be extended to using different coding schemes.
In [16], the authors have shown that such a substream-based mecha-
nism can be applied to several different coding schemes, including
single-layer video, layered coding-based video, and MDC. Since
the use of video quality as an incentive is not our goal here, for sim-
plicity of illustration, we use single-layer video with substreams.
However, as noted earlier, our approach can be combined with lay-
ered coding-based video or MDC schemes.
ti,p ai,p ti,p+1 ai,p+1
Figure 2: Time Interval: peer views streaming content during
time intervalti;p and views advertisements during time interval
a
i;p
Pi Pj Pk
(a)
(b)reuse (c)non-reuse
Serial Number
Timestamp
Pi’s ID
Pj’s ID
Pk’s ID
Serial Number
Timestamp
Pi’s ID
Pj’s ID
# of tokens
Figure 3: Token Structure
In the TSCP and TPCS schemes, when a peer wants to join or de-
part from the overlay system, it has to contact the token server.
The token server keeps login information of each peer, as a way of
checking whether the peer exists in the system or not. The login in-
formation is used when the token server distributes tokens to peers
or calculates a peer’s contribution.
After a peer joins the overlay network, it connects ton neighbors to
download streaming content and advertisements. In addition, peers
randomly choose new neighbors periodically. In the system, a peer
has to provide tokens when it downloads data from other peers.
Conversely, it receives tokens from other peers when it streams
(uploads) data to them. The amount of data, ±, that a peer can
download upon providing one token is determined by the service
provider. Moreover, uploading advertisements is also considered as
a peer’s contribution, since such upload bandwidth contribution can
reduce the load on the streaming server. A peer making a greater
contribution accordingly receives a greater number of tokens from
other peers.
In our system, the downloaded content and advertisements are kept
in the local cache of a peer. Peers must view advertisements after
they have viewed some amount of content. For instance, consider
the example in Fig. 2, where peeri views content in thep-th time
interval, t
i;p
. Then, the system displays advertisements of length
ai;p which is calculated based on peeri’s contribution duringti;p.
Therefore,ai;p is different from interval to interval. The length of
time intervalt
i;p
is the same for every peer, and it is determined by
the service provider. At the end of each time interval, t
i;p
, peers’
contributions are calculated and used to determine the amount of
advertisements that each peer should view. Below, we describe in
detail our token-based schemes and how peers’ contributions are
calculated in our system. For convenience, a summary of notation
used in the paper is given in Table 1.
k number of substreams
n number of a peer’s neighbors
± amount of data a peer can download
per one token
N number of tokens the token server sends
to a peer for each content interval
t
i;p
p-th time interval for viewing content
ai;p p-th time interval for viewing
advertisements
c
i;p
peeri’s contribution duringt
i;p
ri;p number of tokens received by peeri
duringt
i;p
g
i;p
number of tokens generated by peeri
duringti;p
s
i;p
number of tokens sent by peeri
to other peers duringt
i;p
fi;p ratio of advertisement time length
to time length of streamed content
Max(f) maximum value off
i;p
Def(f) default value offi;p
Min(f) minimum value off
i;p
Min(c) a peer’s contribution if it is free-rider
Equal(c) a peer’s contribution while
its income is equal to its spending amount
Table 1: Notations list
Token generation: Now, we describe how to generate tokens in
our system. In the TPCP and TPCS schemes, tokens are gen-
erated by peers; tokens are generated by the token server in the
TSCP scheme. The corresponding token structure is depicted in
Fig. 3(b). Each token has a different serial number and timestamp
for uniqueness. Moreover, a token includes the generator’s ID and
the receiver’s ID. In the TSCP scheme, the generator’s ID is the
token server’s ID, e.g., in Fig. 3, peer i is the generator and peer
j is the receiver. After peeri generates a token, it encrypts the to-
ken to prevent other peers from faking tokens.
1
In the TPCP and
TPCS schemes, peers can generate tokens as needed. In the TSCP
scheme, tokens are generated by the token server. Then, the token
server sends tokens to peers at the start of each content interval,
t
i;p
, as depicted in Fig. 2. The number of tokens sent,N, is suffi-
cient for that peer to download (stream) all content needed for that
content interval. Therefore, a peer does not need to generate tokens
on its own.
Token exchange: The token exchange function is the same for all
schemes. When a peer downloads a stream from other peers, it
can “pay" for it by either (i) using tokens it received from other
peers, or by (ii) generating new tokens, e.g., if that peer does not
have sufficient tokens accumulated from serving other peers. If a
peer pays for content by using received tokens, then the new owner
of that token appends its ID to the token (e.g., peer k’s ID in Fig.
3(b)). In our system, received tokens can be reused, and a peer does
not have to generate new tokens each time it wants to download
(stream) content.
Contribution calculation: Now, we describe how to calculate peers’
contributions and how to calculate the amount of advertisement,
9
1
In our system, we encrypt tokens, rather than use digital signa-
tures. The main reason is that use of encryption results in a more
secure protocol than one with digital signatures. We discuss this in
more detail in Section 4.
a
i;p
, that each peer should watch. In our system, the amount of ad-
vertisement is based on a peer’s resource contribution. Therefore,
we have to calculate the peers’ contributions first. Contribution
calculation is done at the end of ti;p. In the TPCP scheme, peer’s
contribution is calculated the at peer-side. The number of tokens
received by peer i, r
i;p
, is regarded as the peer’s income, and the
number of tokens generated by peer i, g
i;p
, is considered as the
peer’s spending amount. Note that, if a peer reuses its received to-
kens, those tokens are not accounted for inri;p orgi;p. We define
the peer’s contribution,c
i;p
, as the difference betweenr
i;p
andg
i;p
,
normalized by time, i.e.,
ci;p =
r
i;p
¡g
i;p
ti;p
(1)
In the TPCS scheme, the token server is responsible for calculating
contributions. Therefore, peers have to report received tokens to
the token server. The definition of a peer’s contribution in TPCS is
the same as Eq. (1). In the TSCP scheme, a peer’s contribution is
also calculated at the peer-side. However, the definition of a peer’s
contribution is different from Eq. (1). In the TSCP scheme, to-
kens are generated by the token server. Therefore, a peer’s income
includes the number of tokens received from the token server, N,
and the number of tokens received from other peers,ri;p. A peer’s
spending amount is the number of tokens sent to other peers, s
i;p
.
A peer’s contribution in the TSCP scheme,c
i;p
, is
c
i;p
=
N +ri;p¡si;p
t
i;p
(2)
The method used to calculate ai;p is the same in all schemes. We
define fi;p, the ratio of the advertisement time length to the time
length of streaming content, e.g., in Fig. 2, f
i;p
is the ratio of
a
i;p
to t
i;p
. Intuitively, the value of f
i;p
is inversely proportional
to ci;p. Therefore, there are many functions which can be used
to determine the value of fi;p, e.g., exponential, linear, logarithm,
etc. This choice depends on how “quickly" the system would like
to “reward" peer contributions, e.g., if an exponential function is
used, the value off
i;p
would decrease quickly as a peer’s contribu-
tion increases. In this paper, we use a piecewise linear function, as
explained next. We classify peers into three groups based on their
c
i;p
. (The service provider defines default, minimum, and maxi-
mum values off
i;p
, which are described next.) Intuitively, if a peer
is a free-rider who does not contribute resources, its resource con-
tribution is Min(c). The value of Min(c) derived from Eq. (1)
in TPCP and TPCS is¡gi;p=ti;p, and the value ofMin(c) derived
from Eq. (2) in TSCP is(N¡s
i;p
)=t
i;p
. Then, a free-rider’sf
i;p
is
set to the maximum value,Max(f), if it is the maximum length of
advertisements for free-riding. Otherwise, a peer’s fi;p decreases
as its resource contribution increases. If a peer’s income is equal to
its spending amount, its c
i;p
is Equal(c) and its f
i;p
is set to the
default value, Def(f), whereas if a peer’s c
i;p
exceeds a thresh-
old,¸, itsf
i;p
is set to the minimum value,Min(f). The value of
Equal(c) derived from Eq. (1) in TPCP and TPCS is 0, and the
value of Equal(c) derived from Eq. (2) in TSCP is N=ti;p. The
definition off
i;p
is given in Eq. (3), with a corresponding depiction
in Fig. 4.
f
i;p
=
8
>
>
>
>
>
>
>
>
>
<
>
>
>
>
>
>
>
>
>
:
Max(f)¡Def(f)
Min(c)¡Equal(c)
¤c
i;p
+
Min(c)¤Def(f)¡Equal(c)¤Max(f)
Min(c)¡Equal(c)
, ifc
i;p
<0
(Def(f)¡Min(f))
Equal(c)¡¸
¤ci;p+
Equal(c)¤Min(f)¡¸¤Def(f)
Equal(c)¡¸
, if0·ci;p <¸
Min(f) , if¸·c
i;p
(3)
Min(f)
Def(f)
Max(f)
Min(c) Equal(c) λ
f
i,p
c
i,p
Figure 4: The function used by the token server to calculate
f
i;p
.
Finally, we define the amount of advertisement,ai;p, for each peer
i asa
i;p
=f
i;p
¤t
i;p
.
In the TPCP and TSCP schemes, the software at the peer-side cal-
culates each peer’s ai;p. In the TPCS scheme, the token server
sends each peer a message with itsai;p value. After receiving the
a
i;p
value, the display of advertisements, kept in local cache, be-
gins. In addition, the value of f
i;p
is reported to the streaming
server. The streaming server can use this information to decide
on the proportion of advertisements to content, when it distributes
streamed media. We definef as the ratio of advertisements to con-
tent. In our system, the streaming server chooses f to be equal to
the average value off
i;p
.
Reducing overhead: We, now, discuss the issue of token reuse. In
our system, received tokens can be reused, and a peer does not have
to generate new tokens each time it wants to download (stream)
content. An advantage of reusing tokens is the decreased overhead,
particularly the amount of computation needed to perform decryp-
tion at the token server (as each token is signed by its generator
to prevent malicious users from generating fake tokens). We give
an example to demonstrate the computational overhead of decryp-
tion, using an Intel Xeon E5420 and 32GB of memory. There are
10000 strings whose lengths are 1500 bytes, and these strings are
encrypted by 1024 bits RSA. The total time to decrypt these strings
is about 4 minutes. Although the token server can afford such com-
putational overhead, reusing tokens can decrease it. We depict the
token reporting packet structure of reusing tokens and non-reusing
tokens in Fig. 3. The two structures are similar - both include serial
number, timestamp, generator’s ID, and receiver’s ID. The differ-
ence is that in the reusing mechanism, there is a signature of the
token’s new “owner". As a result, one drawback of reusing tokens
is an increase in token reporting packet’s length, as the token’s new
“owner" has to append its signature to the token reporting packet.
If tokens cannot be reused, a peer can send a packet which includes
several tokens, i.e., the last row of the non-reuse packet structure
0
500
1000
1500
2000
2500
0:00 6:00 12:00 18:00 24:00
Number of peers
Time
Figure 5: Population of peers viewing streaming data in the
PPLive system
gives the “number of tokens", as depicted in Fig. 3. However,
even though a packet can include several tokens, the amount of re-
ported packets in the non-reusing mechanism is still higher than
the amount in the reusing mechanism. The reason is that peers
have to report “every” packet in the non-reusing mechanism. We
note that, in the reusing mechanism, each packet indicates only one
token because the receiver cannot split the packet into two packets
with a smaller number of tokens. For example, if peeri sends peer
j a packet which indicates 5 tokens, and the packet has been en-
crypted by peer i, then, peer j cannot divide this packet into two
packets with 2 and 3 tokens, respectively, as the packet has been
encrypted. This limitation may result in more transmitted pack-
ets between peers in the reusing tokens mechanism. In Section 3,
we compare the overhead and corresponding performance of the
reusing tokens and non-reusing tokens mechanisms.
3. EV ALUATION
In this section, we evaluate the proposed token-based schemes. The
goal of this paper is to explore the utility of an approach that uses
advertisements as incentives in P2P streaming systems, rather than
exploring such a system’s implementation. To this end, we use
simulations to demonstrate essential characteristics of our system
and to study its characteristics in a more controlled environment.
An advantage of using simulations is that we can control different
parameters and observe effects of each parameter. We develop a
simulator to evaluate the proposed token-based schemes, where we
use traces to simulate peer dynamics. The traces are available from
the PPLive Project at [4], collected from the PPLive streaming sys-
tem. Specifically, the PPLive crawler takes system snapshots every
ten minutes and records peer IDs. The traces used in our simulation
are collected during one day. Fig. 5 depicts the population of peers
viewing media during a one day period.
The simulator assigns the uploading bandwidth of peers based on
the distribution given Table 2, which corresponds to measurements
in [8]. Because peers typically do not contribute all of their up-
loading capacity, by default (i.e., unless otherwise stated) we be-
gin with a conservative view and consider peers contributing 60%
of their uploading capacity. We also vary this contribution in our
simulations (as detailed below). Furthermore, we assume that the
downloading bandwidth of peers is sufficient to stream the video
(i.e., greater than the streaming rate).
We consider single-layer video in our simulations. As stated in [9],
most video rates in PPLive are between 250 kbps and 400 kbps;
Upload bandwidth (kbps) 256 384 512
Distribution (%) 12 40 31
Upload bandwidth (kbps) 768 1024 2048
Distribution(%) 4 7 6
Table 2: Uploading bandwidth distribution
parameter default value
k 10
n 10
± 500kb
ti;p 10min
Max(f) 1
Def(f) 0.3
Min(f) 0.1
Table 3: Default value of parameters
thus, in our simulations, the video rates of streaming content is 300
kbps. The number of substreams is k = 10, which is the same
as in [16], i.e., the video is divided into 10 substreams, each with
the same video rate. We assume a peer can download an entire
substream from one neighbor. Therefore, in our simulations, peers
connect to 10 neighbors simultaneously. A peer randomly chooses
new neighbors every 30 seconds. (We do not consider peer se-
lection algorithms here since video quality is not the focus of this
work.)
In these experiments, the default amount of data a peer can down-
load from its neighbor when paying one token,±, is 500kb. More-
over, the default value of content interval,ti;p, is 10 minutes (which
is similar to content intervals used in TV programs), and the amount
of advertisements a peer has to view, a
i;p
, is calculated at the end
of each t
i;p
. In what follows, we vary the values of ± andt
i;p
(as
detailed below). Table 3 summarizes the default parameter values.
We now show evaluation results of our system. All results are based
on the following assumptions: tokens are received or reported cor-
rectly and there are no malicious attacks. Because tokens are en-
crypted, we can assume malicious peers cannot fake tokens, and
tokens can be received or reported correctly. We discuss malicious
behavior in Section 4. In our simulations, we need to set the maxi-
mum, default, and minimum values off
i;p
. We setMax(f) = 1.
The time length of advertisement a peer views is not greater than
the time length of content a peer views. In addition, if peer i is a
free-rider, the time length of advertisements it has to view is equal
to the time length of content it has viewed. Then, we set Def(f)
andMin(f) to 0.3 and 0.1, respectively. We base these on statis-
tics given in [24], which show that from 1952 to 2010, the average
offi;p of TV programs increased from 0.15 to 0.47. Because ser-
vice providers of P2P streaming systems may provide fewer adver-
tisements than TV , to attract users, we believe these are reasonable
settings forDef(f) andMin(f). In addition, in our experiments,
we useMin(f) > 0, motivated as follows. As a service provider
can receive revenue from displaying advertisements to peers, it is
likely to have peers view some amount of advertisements. We also
set¸ tog
i;p
=t
i;p
in TPCP and TPCS schemes and to(N+s
i;p
)=t
i;p
in TSCP scheme - that is, if a peer’s received tokens are more than
twice of its generated or sent tokens (derived from Eqs. (1) and
(2)), its fi;p = 0:1. Since, the ratio of average uploading band-
width to streaming rate is less than 2 (in this work), we believe this
is a reasonable threshold setting.
We illustrate that our system can provide peers differentiated ser-
vice, using the amount of advertisements they view, based on their
resource contributions. Fig. 6 demonstrates the average offi;p for
different peer classes in three token-based schemes. The results of
the three schemes are similar because we use the same equation
to calculate a peer’s contribution. The results are not affected by
where tokens are generated and contributions are calculated. Our
results show that the average of fi;p decreases as a peer’s contri-
bution increases. Since the uploading rate of a peer in the first
three classes is less than its downloading rate, itsf
i;p
is higher than
Def(f). If a peer wants to view fewer advertisements, it needs
to increase its uploading rate. Thus, in the next experiment, we in-
crease a peer’s uploading rate from 60% of total uploading capacity
to 70% and 80%. The trends offi;p for different peer classes, under
70% and 80% uploading capacity, are qualitatively similar to those
when uploading bandwidth is 60% of the capacity. Therefore, we
only depict the average off
i;p
in Fig. 7. This figure indicates that
the average offi;p decreases about 28% when a peer increases its
uploading rate from 60% to 80% of the capacity. This indicates
that we can use advertisements as incentives in P2P streaming sys-
tems, i.e., in order to view fewer advertisements, a peer needs to
contribute more.
3.1 Advertisement Distribution
Recall that in our system, after peers download advertisements,
they are kept in the local cache. If the amount of downloaded ad-
vertisement is more than the amount of advertisement a peer has
to view, some downloaded advertisements would not be displayed.
On the other hand, if the amount of downloaded advertisement is
less than the amount of advertisement a peer has to view, some
downloaded advertisements would be repeated.
Therefore, it is an important consideration for the streaming server
to determine how much advertisement should be distributed. That
is, distributing too much advertisement data causes network over-
head and results in some useless advertisements being downloaded
by peers. However, distributing too little advertisement content re-
sults in peers viewing a lot of repeated advertisements. This situ-
ation may not be satisfactory for a service provider as their profit
might depend on how often a particular advertisement is viewed.
We now consider simple strategies for advertisement distribution.
(More sophisticated techniques are possible but are outside the scope
of this paper.)
To this end, we define the following two performance metrics:
² surplus: the ratio of advertisement which is not viewed
relative to all of downloaded advertisement. The value of
surplus is
P
i
[max(f;f
i;p
)¡f
i;p
]
P
i
f
, wheref is the ratio of ad-
vertisement to streamed media content andf
i;p
is based on a
peer’s contribution;
² repeat: the ratio of repeated advertisement to all of down-
loaded advertisement. The value ofrepeat is
P
i
[f
i;p
¡min(f;f
i;p
)]
P
i
f
.
In our experiments, we use three different values of f: Min(f),
Max(f), and the average off
i;p
,Avg(f), and evaluate theirsurplus
and repeat. Because the results of the three schemes are similar,
we show the result from the TPCP scheme only. Based on our ex-
periments, the average ofsurplus andrepeat are depicted in Fig.8
and Fig.9, respectively.
0
0.2
0.4
0.6
0.8
1
256 384 512 768 1024 2048
f
i,p
uploading bandwidth (kbps)
(a) TPCP
0
0.2
0.4
0.6
0.8
1
256 384 512 768 1024 2048
f
i,p
uploading bandwidth (kbps)
(b) TPCS
0
0.2
0.4
0.6
0.8
1
256 384 512 768 1024 2048
f
i,p
uploading bandwidth (kbps)
(c) TSCP
Figure 6: averagef
i;p
for peers with different uploading band-
width in three schemes
The results indicate that using Min(f) as f causes less network
overhead, with no surplus advertisements. However, this strategy
has to display the same advertisement repeatedly. On the other
hand, using Max(f) guarantees that peers do not view repeated
advertisement; however, it results in significant surplus in adver-
tisement content. Fig.8 demonstrates that the average surplus ad-
vertisement is more than 50% of all downloaded advertisement.
One approach to finding a balance between these two metrics is to
useAvg(f). Our results indicate that the average ofsurplus and
repeat (when usingAvg(f)) are both about 0.1. That is, compared
to Min(f) and Max(f), using Avg(f) as f can reduce surplus
advertisement, while also reducing repeated advertisement.
3.2 Reusing tokens vs. Non-reusing tokens
0
0.1
0.2
0.3
0.4
0.5
0.6
60 70 80
f
i,p
uploading ratio (%)
TPCP
TPCS
TSCP
Figure 7: averagef
i;p
for peers with different uploading ratio
in three schemes
We now focus on reusing tokens vs. non-reusing tokens mecha-
nisms. In the above experiments, peers were allowed to reuse re-
ceived tokens. As noted earlier, the main advantage of reusing to-
kens is to reduce overhead of the system, especially in the TPCS
scheme, where peers have to report tokens to the token server.
Since each token has been encrypted by its generator, there is sig-
nificant overhead involved in the token decryption process; hence,
it is the motivation for reusing tokens in our system. In this section,
we use results from the TPCS scheme. Now, recall that in the non-
reuse mechanism, after a peer receives tokens from its neighbors,
it reports these tokens to the token server immediately, whereas in
the reuse mechanisms, a peer can reuse received tokens.
Firstly, we focus on the overhead of these two mechanisms. We
first define the following parameter.
² ®: the average number of packets reported to the token server
by each peer during time interval ti;p. The value of ® is
# of packets
(# of peers)*t
i;p
. Since the token server’s overhead increases
as the value of® increases, our goal is to reduce®.
Fig.10 depicts the value of® in these two mechanisms under differ-
ent values of±. In the non-reuse mechanism,® remains constant as
a function of±. The reason for this is that in the non-reuse scheme,
each packet can include several tokens, as shown in Fig. 3. Fig.10
illustrates that® decreases in the reuse mechanism as± increases.
This indicates that the reuse mechanism reports fewer packets than
the non-reuse mechanism when± is sufficiently large (e.g., 250kb
and 500kb in our experiments). Hence, reusing tokens can reduce
overhead. However, the performance of the reuse mechanism de-
grades when± is too small (e.g., 100kb in our experiments). If± is
too small, a peer has to generate too many tokens. Then, the reuse
mechanism behaves worse in terms of overhead than the non-reuse
mechanism. Thus, the value of ± should not be too small; other-
wise, peers would generate too many tokens, thus increasing the
token server’s overhead.
3.3 Content Interval, t
i;p
Now, we focus on the effects oft
i;p
. If the service provider chooses
a small value of ti;p, then the system can reflect peers’ behavior
better. However, ifti;p is too small, the system interrupts peers fre-
quently to display advertisements, which would not lead to good
service. Thus, we focus on whether choosing different content in-
0
0.1
0.2
0.3
0.4
0.5
0.6
Min(f) Max(f) Avg(f)
surplus
f
Figure 8: The average ofsurplus by using differentf
0
0.5
1
1.5
2
2.5
Min(f) Max(f) Avg(f)
repeat
f
Figure 9: The average ofrepeat by using differentf
0
5
10
15
20
25
30
100 250 500
α
δ (kb)
reuse
nonreuse
Figure 10: The value of® under different±
tervals,t
i;p
, affects accuracy when calculating peers’ contribution.
We also consider overhead at the token server under different t
i;p
values. Therefore, we use results from the TPCS scheme.
We varyt
i;p
from 1 minute to 20 minutes and calculatef
i;p
under
differentt
i;p
’s. We usef
i;p
with the 1 minute setting as our base-
line. Then, we define difference as the difference between f
i;p
under differentti;p’s and the baseline. The equation fordifference
is
P
i
jf
i;p
¡f
baseline
i;p
j
P
i
f
baseline
i;p
, and the results are given in Fig.11. (Here, we
focus on the overall system performance rather than on per class
behavior.)
0
0.2
0.4
0.6
0.8
1
1.2
2 5 10 20
difference (%)
t
i,p
(min)
Figure 11: The average ofdifference under differentt
i;p
0
0.5
1
1.5
2
2.5
3
3.5
60 80 100
difference (%)
uploading ratio (%)
Figure 12: The average of difference when peer’s uploading
ratio changes from 60% to 100%,t
i;p
= 10 min
When t
i;p
increases, the difference also increases. By using
short ti;p, the system can account for peers’ contributions in real
time. On the other hand, if the system updates using longer time
intervals, the results represent peers’ average contributions during
t
i;p
.
In addition to ti;p, peers’ uploading rate also affects results. In
Fig.12,ti;p is fixed at 10 min, and a peer’s uploading rate changes
from 60% of upload capacity to 100%. The results indicate that
thedifference increases when a peer increases its uploading rate.
When a peer increases its uploading rate to 100% of the capac-
ity, the average uploading bandwidth is higher than the video rate.
Then, a peer has more choices when selecting from which peers
to download. Therefore, the number of uploading connections for
each peer may change dramatically while the number of download-
ing connections stays the same. In such a case, the difference
may increase.
We now consider the token server’s overhead under differentt
i;p
’s.
We depict®, the average number of reported tokens, in Fig.13(a).
In addition, we define¯ as the average number of times each token
has been reused, with results depicted in Fig.13(b). Fig.13 demon-
strates that ® decreases and ¯ increases, when the token server
chooses longer t
i;p
’s. The results indicate that using longer t
i;p
’s
can reduce overhead at the token server, i.e., tokens can be reused
more times whenti;p is longer.
4. DISCUSSION
0
1
2
3
4
5
6
5 10 20
α
t
i,p
(min)
(a)®: the average number of reported tokens
0
1
2
3
4
5
6
7
8
9
5 10 20
β
t
i,p
(min)
(b)¯: the average number of times each token has been reused
Figure 13: The overhead in token servers.
Extending to multi-layer streaming: Our experiments use single-
layer streaming. However, our token-based schemes can be ex-
tended to multi-layer-based streaming. Briefly, in the TPCP and
TPCS schemes, a peer with low uploading bandwidth can just down-
load the base layer and generate fewer tokens. A peer with high up-
load bandwidth can download more enhanced layers and pay more
tokens. In the TSCP scheme, the token server sends peers tokens.
Although the number of tokens is sufficient to download all stream-
ing content, including base and enhanced layers, a peer with low
upload bandwidth can just download the base layer and keep the
rest of the tokens. In such a case, its contribution can increase be-
cause its s
i;p
decreases as shown in Eq. (2). The usage depends
on a peer’s preference. If a peer prefers higher video quality, it can
use the tokens to obtain enhanced layers and view more advertise-
ment. Otherwise, a peer can choose lower video quality streaming
and view fewer advertisements.
Overhead of distributing advertisement: In our system, peers
have to download advertisements. When peers’ connection capac-
ities are poor, distribution of advertisements may make such a sit-
uation even worse. There are two possible solutions for solving
the problem. The first solution is to pre-load advertisements be-
fore peers start to download content. Then, peers can just down-
load content later. The second solution is to display downloaded
advertisements repeatedly. Therefore, peers do not have to down-
load new advertisements and can save bandwidth for downloading
content. However, the two solutions may conflict with the service
provider’s profit. The service provider may prefer that peers watch
new advertisements each time. In such a case, the service provider
can deliver low quality advertisements or different types of adver-
tisements whose sizes are small, such as flash animation, to reduce
transmission overhead.
Overhead of token decryption: In our system, every token is en-
crypted to prevent peers from faking tokens. However, decryption
is a significant computational overhead in our system. Therefore,
in order to reduce such overhead, peers are allowed to reuse to-
kens. When the length of a token is sufficiently large, an alterna-
tive mechanism that can reduce computational overhead is the use
of digital signatures. In such a mechanism, peeri uses hash func-
tions to generate a message digest of a token. Then, peeri encrypts
the message digest with its private key. The result is peeri’s digital
signature for the token. Finally, peeri appends the digital signature
to the token. After peer j receives this token from peer i, peer j
can decrypt the signature by using peer i’s public key and verify
whether the token is sent by peeri. Because the length of a digital
signature is shorter than the length of a token, the overhead of de-
crypting a digital signature is less than the overhead of decrypting
an encrypted token. However, this would prove that a token is sent
by a specific peer, but will not prevent peers from faking tokens.
After malicious peers receive tokens with digital signatures, they
can extract tokens’ content and fake tokens. In addition, malicious
peers can just remove appended digital signatures from tokens and
modify tokens. This is in contrast to encryption algorithms where
a token can be decrypted only by token servers. Hence, we adopt
encryption algorithms.
4.1 Comparisons between token-based schemes
In Section 3, we show that using different schemes does not affect
peers’ contribution. In this paper, the motivation for considering
different schemes is to explore several issues. We discuss these
issues below.
Reliability: First, we discuss reliability characteristics of the three
schemes. Among these schemes, TPCP is more reliable than TPCS
and TSCP. The reason is that TPCP is a distributed scheme and it
does not have to worry about token server failure. However, in the
other schemes, the system has to deal with token server failure. In
TPCS, the token server is responsible for calculating peers’ con-
tributions and informing peers about the amount of advertisement
they have to watch. If the token server fails, peers do not know how
much advertisement they have to watch. To solve this problem, we
can set a timer. If the waiting time for a token server’s message
exceeds the timer, the system starts to display advertisements. The
length of advertisements can be based on peers’ history or the de-
fault value set by the service provider. In TSCP, the token server is
responsible for delivering tokens to peers. If the token server fails,
there are no tokens sent to peers, and peers cannot download data
because of lack of tokens. In our future work, we will focus on how
to increase system reliability.
Overhead: In all token-based schemes, token generation, distri-
bution, and decryption all represent overhead for the system. In
TPCP, the overhead is shared by peers. However, in TPCS and
TSCP, the token server has to deal with tokens. In TPCS, the token
server needs to decrypt tokens before it calculates peers’ contri-
butions. To reduce decryption overhead, we propose the reusing
token mechanism, and our results demonstrate that this mechanism
can reduce the amount of reported tokens. In the TSCP scheme, the
token server is responsible for encrypting and distributing tokens to
peers. To reduce such overhead, the token server can send tokens
using a staggered schedule, rather than sending tokens to all peers
at once. However, this may reduce system reliability.
Token Management: Although TPCS and TSCP are less reliable
than TPCP, they result in better token management. In TSCP, to-
kens are generated by the token server. Therefore, the token server
can control the number of tokens distributed to peers and force
peers to contribute their resources. In this paper, we assume the
number of tokens generated by the token server is enough for peers
to download the entire content. In order to force peers to contribute
resources, the token server can generate fewer tokens. In such a
case, peers would have to contribute more to earn more tokens
for downloading the entire content. In TPCS, tokens are reported
to the token server. Therefore, the token server has better infor-
mation about peers’ contributions and behavior. The information
can be used for further system analysis and development. Service
providers can use the information to decide how to distribute adver-
tisements and which advertisements should be distributed. In our
system, we use the information to determine the amount of adver-
tisements distributed during each time interval. Service providers
can use different mechanisms. For example, since service providers
must satisfy advertisers’ needs, they can design a display schedule
of advertisements based on how long peers watch advertisements
and make sure every advertisement is viewed at least a specific
number of times. They can also have several schedules to maxi-
mize revenues based on different peers’ behavior. Another exam-
ple is that service providers can change system settings based on
peers’ behavior. They can measure how much bandwidth peers are
willing to contribute and determine whether they should increase or
decrease the amount of advertisements. Such directions are outside
the scope of this paper and are part of future efforts. In addition,
peers’ contributions are calculated by the token server in TPCS. It
can eliminate falsifying contributions at the peer-side.
Malicious attacks: The motivation for using token-based schemes,
in addition to reporting contributions by peers, is to determine true
peers’ contributions. Using encrypted tokens can also prevent peers
from faking tokens. Here, we discuss some attack methods and
show how to protect our system from these attacks.
One possible attack is from colluding peers. For instance, a peer
with high upload bandwidth can forward its tokens to other peers
without receiving uploads, in order to help them increase their con-
tributions. To address this attack, when the system calculates a
peer’s contribution, it can consider a peer’s income and spending
amount simultaneously. For example, when malicious peers for-
ward their tokens to others, the tokens would be considered as their
spending. When their spending amount increases, their contribu-
tion would decrease. Thus, malicious peers would hurt their con-
tributions by forwarding their tokens to other peers. Another so-
lution is for service providers to change contribution calculation
functions. We give two possible methods to demonstrate the idea
of how to modify such functions. We define ti as the number of
tokens peeri has andci as its contribution. In this paper, we use a
linear function to calculatec
i
. Therefore, one possibility for service
providers is to change coefficients of the function. For example, the
contribution calculated by the new function, c
new
i
, is
c
i
k
, where k
is larger than 1. In such a case, a peer needsk times the number of
tokens to maintain the same contribution. Another alternative for
service providers is to consider non-liner functions. Then, when
a peer receives a token, the increased value of its contribution is
different and is based on the number of tokens it has. For exam-
ple, service providers can use an exponential function to calculate
peers’ contributions (e.g., c
new
i
= e
t
i
). In such a case, when a
peer forwards its tokens to other peers, the decreased value of its
contribution may be larger than the increased value of other peers’
contributions. Therefore, it may cause a significant loss for mali-
cious peers’ contributions to forward their tokens to others. The
solutions may not eliminate colluding attacks totally if a peer has a
lot of tokens. However, such solutions can reduce the the number
of peers that can participate.
Another possible attack in TPCS is to ignore messages from the
token server. For this attack, the solution is the same as the method
used when the token server is down. The software will display
advertisements after a set timer is exceeded.
Finally, in TPCP and TSCP, contributions are calculated at the peer-
side. Therefore, malicious peers may try to modify software param-
eters, such as Max(f), Def(f), and Min(f), and affect results
of contribution calculation. However, to execute such attacks, ma-
licious peers need to modify the software. It is typically difficult
(i.e., requires a certain level of expertise) to make such modifica-
tions. This issue is outside the scope of this paper and is part of
future efforts.
5. RELATED WORK
Since P2P streaming services became popular, there has been a
number of efforts focusing on measurement and analysis of P2P
streaming systems, e.g., as in [9, 12, 27]. For instance, [9] and [27]
both focus on the PPLive system [3], where [9] characterizes user
behavior and traffic profiles, while [27] indicates characteristics of
the PPLive system that are different from those of P2P file-sharing
systems. In [12] the authors focus on the Coolstreaming system
and discuss various associated issues, including highly skewed re-
source distribution, excessive start-up time, and high failure rates
during flash crowds. These works demonstrate several character-
istics of existing P2P streaming systems that could be helpful for
improving current streaming systems or designing future systems.
Although several deployed systems have a significant number of
users, [3, 5, 6, 30], the architectures of these systems are not open.
Therefore, a number of other design efforts can be found in the lit-
erature, e.g., [22, 28]. For instance, [22] proposes an unstructured,
mesh-based system and indicates that in such systems, the tit-for-
tat mechanism can result in reasonable streaming performance. In
[28], the authors investigate a framework for multi-channel P2P
streaming systems, which can address two problems, excessively
long channel switching delays and poor performance in channels
with a small number of peers.
One of the main challenges in P2P streaming systems is provision
of incentives for users to contribute their resources to the system
- these are the efforts that, in terms of a high level goal (i.e., in-
centives) are closer to ours. A number of efforts have consid-
ered this problem, from a variety of perspectives, e.g., [10, 14–
16, 20, 21, 23]. For instance, [14] and [15] propose layered cod-
ing/MDC schemes with a tit-for-tat type strategy. The schemes use
video quality as an incentive for peers to increase their upload rates.
In [10], the authors design an unstructured protocol that can re-
duce the end-to-end streaming delay and improve delivered content
quality. Specifically, they combine a push-pull scheme and a score-
based scheme as an incentive method. In [23], the authors address
two main problems in tree-based systems and propose an unstruc-
tured swarm overlay system. A credit-based incentive scheme is
adopted in order to fully utilize upload bandwidth. In [21] the au-
thors study the effects of a local pairwise incentive mechanism and
focus on resource availability and the average quality of paths. The
work in [20] demonstrates that a tit-for-tat scheme may not work
well in streaming systems due to bandwidth and delay constraints.
In order to solve such a problem, an incentive scheme (termed To-
ken Stealing), based on an Iterated Prisoner’s Dilemma, is pro-
posed. Lastly, [16] proposes a substreaming framework that can
be applied to a variety of video coding schemes, including single-
layer video, layered video, MDC, and simulcast. This work designs
a partner selection scheme, based on a tit-for-tat mechanism. The
goal of this partner selection scheme is to provide better streamed
media qualify for peers who can make greater contributions.
While the above works provide interesting insight into P2P stream-
ing systems, to the best of our knowledge, our work is the first
to use advertisements as an incentive in P2P streaming systems.
Our results demonstrate, that, in addition to streamed media qual-
ity, advertisements could provide another useful incentive for peers
to contribute their resources to the system. Thus, our work provides
system developers another choice for peer incentives. Moreover,
our efforts are orthogonal to those on media quality incentives, i.e.,
both can be combined in one system. For instance, as discussed in
Section 4, a peer can choose different levels of media quality and
different amounts of advertisements, based on its needs. That is,
our schemes can be combined with other related efforts - e.g., sys-
tem developers can provide streamed media quality and fewer ad-
vertisements as incentives by applying peer selection strategies or
layered coding techniques in the context of our framework, such as
adopting layered video coding with the substreaming framework.
Another factor in our framework is the use of token-based schemes,
in order to account for peers’ contributions. The use of token-based
scheme in P2P file sharing systems can be found, e.g., in [13, 19,
26, 29]. Most of these efforts focus on credit type systems or micro-
payment type systems for P2P service, using token-based schemes.
In these systems, peers can exchange tokens, as virtual currency, to
receive resources or service. For instance, [19] discusses two com-
mon incentive methods, reputation and payment protocols, which
share some common characteristics. Specifically, a general proto-
col is discussed (termed, stamp trading), that has properties of the
two methods and can satisfy trust and token-compatibility require-
ments. In [29], the authors design a micro-payment system for P2P
applications, while [26] uses self-issued tokens for accounting in a
Grid computing type system. In [13], the authors design a decen-
tralized token-based accounting scheme, where tokens are regarded
as proof of resource or service usage. This scheme is used to collect
transaction accounting information, which can provide a basis for
pricing and can be used to control the behavior of peers, to achieve
better system performance. In our work, we adopt the concept of
using tokens as payment in designing our system. Our main pur-
pose in utilizing tokens is to create a mechanism for accounting
for peers’ contributions. Our main goal, however, is to propose an
incentive scheme that uses advertisements as incentives for peers
to contribute. This goal is different from previous works that use
tokens for charging for services, representing reputation, or down-
loading data.
6. CONCLUSIONS
In this paper, we proposed an incentive mechanism, in the context
of P2P streaming systems, for peers to contribute their upload re-
sources. In contrast to previous efforts that used quality of streamed
media as an incentive, we suggested that service providers can use
advertisements as an incentive and proposed a framework for doing
so. Our experimental evaluations indicate that our approach can
encourage peers to contribute greater amounts of their upload re-
sources. Our framework design includes three token-based schemes,
which help avoid malicious peer behavior, i.e., reporting of fake
contributions. We discuss various properties of our token-based
schemes. Our experimental results provide guidelines and intuition
for the various parameter settings in our framework. Our approach
is orthogonal to earlier efforts in the literature, using media quality
as an incentive..
References
[1] BitTorrent. http://www.bittorrent.com/.
[2] Hulu. http://www.hulu.com/.
[3] PPLive. http://www.pplive.com/.
[4] PPLive Project.
http://cairo.cs.uiuc.edu/ longvu2/pplive.html.
[5] PPStream. http://www.ppstream.com/.
[6] TVUPlayer. http://www.tvunetworks.com/.
[7] YouTube. http://www.youtube.com/.
[8] M. Dischinger, A. Haeberlen, K. P. Gummadi, and S. Saroiu.
Characterizing residential broadband networks. In Proceed-
ings of the 7th ACM SIGCOMM conference on Internet mea-
surement, pages 43–56, 2007.
[9] X. Hei, C. Liang, J. Liang, Y . Liu, and K. Ross. A measure-
ment study of a large-scale p2p iptv system. IEEE Transac-
tions on Multimedia, 9(8):1672–1687, Dec. 2007.
[10] P. K. Hoong and H. Matsuo. Push-pull incentive-based p2p
live media streaming system. WSEAS Transactions on Com-
munications, 7:33–42, Feb. 2008.
[11] R. Kumar, Y . Liu, and K. Ross. Stochastic fluid theory for
p2p streaming systems. In Proceedings of IEEE INFOCOM,
2007.
[12] B. Li, S. Xie, G. Keung, J. Liu, I. Stoica, H. Zhang, and
X. Zhang. An empirical study of the coolstreaming+ sys-
tem. IEEE Journal on Selected Areas in Communications,
25(9):1627–1639, Dec. 2007.
[13] N. Liebau, O. Heckmann, A. Kovacevic, A. Mauthe, and
R. Steinmetz. Charging in peer-to-peer systems based on a
token accounting system. In the 5th International Workshop
on Advanced Internet Charging and QoS Technologies, pages
49–60, 2006.
[14] Z. Liu, Y . Shen, S. Panwar, K. Ross, and Y . Wang. P2P video
live streaming with MDC: Providing incentives for redistri-
bution. In IEEE International Conference on Multimedia and
Expo, pages 48–51, July 2007.
[15] Z. Liu, Y . Shen, S. S. Panwar, K. W. Ross, and Y . Wang. Using
layered video to provide incentives in p2p live streaming. In
Proceedings of the workshop on Peer-to-peer streaming and
IP-TV, pages 311–316. ACM, 2007.
[16] Z. Liu, Y . Shen, K. Ross, S. Panwar, and Y . Wang. Substream
trading: Towards an open p2p live streaming system. In IEEE
International Conference on Network Protocols, pages 94–
103, Oct. 2008.
[17] Z. Liu, Y . Shen, K. Ross, S. Panwar, and Y . Wang. Layerp2p:
Using layered video chunks in p2p live streaming. IEEE
Transactions on Multimedia, 11(7):1340–1352, Nov. 2009.
[18] J. J. D. Mol, D. H. J. Epema, and H. J. Sips. The orchard al-
gorithm: P2p multicasting without free-riding. In IEEE Inter-
national Conference on Peer-to-Peer Computing, pages 275–
282, 2006.
[19] T. Moreton and A. Twigg. Trading in trust, tokens and stamps.
In Proceedings of the 2nd Workshop on Economics of Peer-to-
Peer Systems, 2003.
[20] V . Pai and A. E. Mohr. Improving robustness of peer-to-peer
streaming with incentives. In Proceedings of the First Work-
shop on the Economics of Networked Systems, 2006.
[21] F. Pianese and D. Perino. Resource and locality awareness in
an incentive-based p2p live streaming system. In Proceedings
of the workshop on Peer-to-peer streaming and IP-TV, pages
317–322. ACM, 2007.
[22] F. Pianese, D. Perino, J. Keller, and E. W. Biersack. Pulse:
An adaptive, incentive-based, unstructured p2p live streaming
system. IEEE Transactions on Multimedia, 9(8):1645–1660,
2007.
[23] T. Qiu, I. Nikolaidis, and F. Li. On the design of incentive-
aware p2p streaming. Journal of Internet Engineering,
1(2):61–71, 2007.
[24] W. Schmidt. How Much TV Commer-
cial Length has Grown over the Years.
http://www.waynesthisandthat.com/commerciallength.htm.
[25] T. Silverston, O. Fourmaux, and J. Crowcroft. Towards an in-
centive mechanism for peer-to-peer multimedia live stream-
ing systems. In IEEE International Conference on Peer-to-
Peer Computing, pages 125–128, Sep. 2008.
[26] W. Thigpen, T. J. Hacker, L. F. Mcginnis, and B. D. Athey.
Distributed accounting on the grid. In Proceedings of the 6th
Joint Conference on Information Sciences, pages 1147–1150,
2002.
[27] L. Vu, I. Gupta, J. Liang, and K. Nahrstedt. Measurement
and modeling of a large-scale overlay for multimedia stream-
ing. In the International ICST Conference on Heterogeneous
Networking for Quality, Reliability, Security and Robustness,
2007.
[28] D. Wu, C. Liang, Y . Liu, and K. Ross. View-upload decou-
pling: A redesign of multi-channel p2p video systems. In
Proceedings of IEEE INFOCOM, 2009.
[29] B. Yang and H. Garcia-Molina. Ppay: micropayments for
peer-to-peer systems. In Proceedings of the 10th ACM confer-
ence on Computer and communications security, pages 300–
310, 2003.
[30] X. Zhang, J. Liu, B. Li, and T.-S. P. Yum. Coolstream-
ing/donet: A data-driven overlay network for peer-to-peer live
media streaming. In Proceedings of IEEE INFOCOM, 2005.

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

USC Computer Science Technical Reports, no. 919 (2011)

PDF

USC Computer Science Technical Reports, no. 904 (2009)

PDF

USC Computer Science Technical Reports, no. 913 (2009)

PDF

USC Computer Science Technical Reports, no. 928 (2012)

PDF

USC Computer Science Technical Reports, no. 815 (2004)

PDF

USC Computer Science Technical Reports, no. 888 (2007)

PDF

USC Computer Science Technical Reports, no. 917 (2010)

PDF

USC Computer Science Technical Reports, no. 969 (2016)

PDF

USC Computer Science Technical Reports, no. 923 (2012)

PDF

USC Computer Science Technical Reports, no. 918 (2010)

PDF

USC Computer Science Technical Reports, no. 906 (2009)

PDF

USC Computer Science Technical Reports, no. 905 (2009)

PDF

USC Computer Science Technical Reports, no. 766 (2002)

PDF

USC Computer Science Technical Reports, no. 920 (2011)

PDF

USC Computer Science Technical Reports, no. 894 (2008)

PDF

USC Computer Science Technical Reports, no. 834 (2004)

PDF

USC Computer Science Technical Reports, no. 914 (2010)

PDF

USC Computer Science Technical Reports, no. 871 (2005)

PDF

USC Computer Science Technical Reports, no. 929 (2012)

PDF

USC Computer Science Technical Reports, no. 835 (2004)

Description

Bo-Chun Wang, Alix L.H. Chow and Leana Golubchik. "P2P streaming: A study on the use of advertisements as incentives." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 924 (2012).

Asset Metadata

Creator Chow, Alix L.H. (author), Golubchik, Leana (author), Wang, Bo-Chun (author)

Core Title USC Computer Science Technical Reports, no. 924 (2012)

Alternative Title P2P streaming: A study on the use of advertisements as incentives (title)

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)

Tag OAI-PMH Harvest

Format 12 pages (extent), technical reports (aat)

Language English

Unique identifier UC16269490

Identifier 12-924 P2P Streaming a Study on the Use of Advertisements as Incentives (filename)

Legacy Identifier usc-cstr-12-924

Format 12 pages (extent),technical reports (aat)

Rights Department of Computer Science (University of Southern California) and the author(s).

Internet Media Type application/pdf

Source 20180426-rozan-cstechreports-shoaf (batch), Computer Science Technical Report Archive (collection), University of Southern California. Department of Computer Science. Technical Reports (series)

Access Conditions The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Repository Email csdept@usc.edu

Inherited Values

Title Computer Science Technical Report Archive

Description Archive of computer science technical reports published by the USC Department of Computer Science from 1991 - 2017.

Coverage Temporal 1991/2017

Repository Email csdept@usc.edu

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)