Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
Computer Science Technical Report Archive
/
USC Computer Science Technical Reports, no. 919 (2011)
(USC DC Other)
USC Computer Science Technical Reports, no. 919 (2011)
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
P2P Streaming Systems: a Study on the Use of Advertisements as Incentives
Bo-Chun Wang
¤
, Alix L.H. Chow
y
, Leana Golubchik
¤
¤
Computer Science Department
University of Southern California, Los Angeles, California
Email: fbochunwa,leanag@usc.edu
y
Nokia Research Center, Beijing, China
Email: alix.chow@nokia.com
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 providing
streaming services is that of providing appropriate incen-
tives for peers to contribute their upload capacity. To this
end, in this paper, we propose the use of advertisements as
an incentive for peers to contribute upload capacity. In the
proposed system, peers enjoy the same quality of streamed
media, with the difference in quality of service being
achieved through different amounts of advertisements they
view, based on their resource contributions to the system.
We also present an extensive simulation-based study, used
to evaluate the proposed scheme. The results demonstrate
that our proposed approach can provide appropriate incen-
tives for peers to contribute their resources to the system.
Keywords-P2P streaming systems; incentives; advertise-
ments; token-based systems.
I. Introduction
The use of Peer-to-Peer (P2P) technology has led to
efficient distribution of content over large scale networks.
For instance, BitTorrent [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 approached,
due to the following advantages: low cost, scalability,
and ease of deployment. There are already several P2P
streaming applications deployed on the Internet, such as
PPLive [2], PPStream [4], and TVUPlayer [5]. Moreover,
a number of efforts have focused on measurement and
analysis of such P2P streaming systems [7, 9, 24].
However, P2P streaming systems still suffer from free-
riding problems, i.e., similar to the free-riding problems
observed in P2P file sharing systems. Moreover, previous
efforts have shown that deployed streaming systems’ per-
formance depends on peers with high upload capacities,
given that there is a significant upload bandwidth hetero-
geneity in the Internet [7]. Therefore, the problem of how
to provide appropriate incentives for peers to contribute
their upload 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 typically
provide a reduction in file downloading time as an incen-
tive. However, in streaming systems, a peer’s quality of
service depends on streaming 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 appropriate
incentives for peers to contribute resources in the context
of P2P streaming systems.
To address this incentives problem in streaming sys-
tems, several techniques have been proposed in the litera-
ture, such as [8, 11–13, 15, 17, 18, 20, 22]. Most of these
works use improved video quality as an incentive, achieved
through layered coding-based or MDC-based techniques
[11, 12, 14]. Briefly, the basic idea here is that peers will
have better streaming quality when they upload more data.
(A more detailed description of related work is given in
Section IV.)
In this paper we consider an alternative direction for
providing incentives in P2P streaming systems, namely that
of using advertisements as an incentive to contribute more
resources, as described next. Our approach is orthogonal to
(and can be combined with) previous efforts whose goals
are to provide better streaming quality. (More details are
provided later in the paper.)
Advertisement supported service has become a popular
business model. Thus, advertisements could provide addi-
tional revenue for the service provider in a P2P streaming
system. That is, service providers would include adver-
tisements in the distributed content (e.g., as is currently
done on television). Since all peers (whether high or
low capacity) are concerned about streaming 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 similar 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 “pay-
ment” we consider is the peers’ resource contributions.)
Briefly, in our proposed system, peers who contribute more
upload capacity view fewer advertisements than peers who
contribute less upload resources, as depicted in Fig. 1.
Thus, unlike in layered coding/MDC based schemes, low
capacity peers can still enjoy good streaming quality but
with more advertisements than higher capacity peers. In
this paper, we focus on the architecture of such a system
and its evaluation.
One important challenge in such a system is accounting
for peers’ contributions, on which the system can in turn
base the computation of the amount of advertisements a
peer should view. One possible approach is to allow peers
to report their own contributions. 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
contribution each peer is making. The concept of token-
based schemes has been used in P2P file sharing systems,
e.g., as in [10, 16, 23, 26], as a form of credit systems
or micro-payment systems, where peers can exchange
tokens, as virtual currency, to receive resources or services.
That is, peers “pay” with tokens for downloading content
and receive tokens for uploading content to other peers
[10]. In this paper, we adopt the idea of using tokens
as payment in designing our system. However, our main
purpose in utilizing tokens is in creating a mechanism for
accounting for peers’ contributions. (The details of our
system architecture are given in the following section.)
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. One advantage of this
token-based approach is that the use of tokens can prevent
malicious 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 signatures.
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 architecture. Since, advertise-
ment supported services are likely to become more
and more popular, our approach could provide peers
an important incentive for contributing their upload
capacity. In Section III, our simulation-based study
demonstrates the utility of this approach - for instance,
when peers increase their uploading rate, the system
provides appropriate amount of advertisement based
on true contributions.
² We propose token-based schemes as an approach to
addressing the problem of accounting for peers’ true
resource contributions in Section II. In Section III,
we present our simulation-based study that illustrates
several useful characteristics of our schemes. These
include, a demonstration of how to reduce overhead
needed for implementing such token-based schemes
in Section III-A1 and what are the tradeoffs between
overhead reduction and accuracy in Section III-A2.
Moreover, we also focus on efficient distribution of
advertisements in Section III-A3. Our results provide
system developers with insight into efficient devel-
opment of P2P-based streaming systems that utilize
advertisements as incentives for resource contribution.
II. . The Proposed System
In this section, we present the proposed system which
uses advertisements as incentives in a P2P streaming
system. In this system, peers view different amounts of
advertisements, based on their resource contribution 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,
Streaming Server Token Server
Streamed media
Tokens
Advertisement
Peer with high
uploading rate
Peer with low
uploading rate
Fig. 1. System Architecture
in this paper we focus on one type of advertisement,
namely streamed media.
The main challenge in our system is that of deter-
mining peers’ true resource contributions. One possible
approach is to allow peers to report their own contributions.
However, this method dose not prevent 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, with
the corresponding system architecture illustrated in Fig.
1. The system consists of a streaming server, a token
server, and peers. 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 keeping track of and computing peers’
resource contributions.
The streaming format considered in the remainder of
the paper is single-layer video with substreams, as in [13].
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 substreams is it can be
extended to different coding schemes. In [13], the authors
have shown that such a substream-based mechanism 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 simplicity of illustration (in this paper), we
use single-layer video with substreams. However, as noted
earlier, our approach can be combined with layered coding-
based video or MDC schemes.
When a peer wants to join or depart 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 information is used when the token server calculates
a peer’s contribution or distributes tokens to peers. (A
detailed description is given below.)
After a peer joins the overlay network, it connects to n
neighbors to download streaming content and advertise-
ments. The downloaded advertisements are kept in the
local cache of a peer. In what follows, we discuss how
advertisements are displayed. In addition, peers randomly
choose new neighbors every 30 seconds. 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 token server. 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 this paper, we propose two schemes, with the two dif-
fering in their token generation and management approach.
The motivation for considering two different schemes is
to explore the trade-off between additional overhead at
the token server (due to token management) and the
corresponding improvement in accuracy of information
about each peer’s resource contribution. Briefly, in the first
scheme, tokens are generated by peers while in the second
scheme, the tokens are generated by the token server. We
compare these schemes in terms of their overhead and
corresponding performance in Section III.
We now describe the two schemes in detail below. For
convenience, a summary of notation used in the paper is
given in Table I.
A. Peers Token Generating Scheme
In the peers token generating scheme, tokens are gen-
erated by peers. The corresponding token structure is
depicted in Fig. 2(b). Each token has a different serial
number and timestamp, to make sure that every token is
unique. Moreover, a token includes the generator’s ID and
the receiver’s ID. For instance, in Fig. 2, peer i is the
k number of substreams
n number of a peer’s neighbors
± amount of data a peer can download
per one token
t
i;p
p-th time interval for viewing content
a
i;p
p-th time interval for viewing
advertisements
r
i;p
number of tokens reported by peer i
during t
i;p
s
i;p
number of tokens generated by peer i
during t
i;p
c
i;p
peer i’s contribution during t
i;p
f
i;p
ratio of advertisement time length
to time length of streamed content
Max(f) maximum value of f
i;p
Def(f) default value of f
i;p
Min(f) minimum value of f
i;p
L time length of advertisements in a
peer’s local cache
N number of tokens the token server sends
to a peer for each content interval
T
i;p
number of tokens peer i has at the
end of t
i;p
¹ how much advertisement a peer can
delete from its local cache
° minimum time length of advertisements
that a peer has to view
TABLE I. Notations list
generator and peer j is the receiver. After peer i generates
a token, it encrypts the token with its private key to prevent
other peers from faking tokens. 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. 2(b)).
In this system, peers must view advertisements after
they have viewed some amount of content. For instance,
consider the example in Fig. 3, where peeri views content
in the p-th time interval, t
i;p
. Then, the system displays
advertisements corresponding to time length a
i;p
. The
length of a
i;p
is calculated based on peer i’s contribution
during t
i;p
. Therefore, a
i;p
is different from interval to
interval. The length of time interval t
i;p
is the same for
every peer, and it is determined by the token server. When
a peer joins the system, the token server notifies the peer
of the length of t
i;p
. The time length of a
i;p
is calculated
by the token server based on peeri’s resource contribution
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
Fig. 2. Token Structure
ti,p ai,p ti,p+1 ai,p+1
Fig. 3. Time Interval: peer views streaming
content during time interval t
i;p
and views
advertisements during time intervala
i;p
duringt
i;p
. Therefore, peers have to report received tokens,
as their contributions, to the token server at the end oft
i;p
.
At the end of each time interval, t
i;p
, the token server
calculates peers’ contributions, based on the reported to-
kens, and determines the amount of advertisements that
each peer should view. Below, we describe in detail how
the token server calculates the peers’ contributions.
There are three steps to calculating the amount of
advertisement, a
i;p
, that each peer should view. In our
system, the amount of advertisement is based on a peer’s
resource contribution. Therefore, in the first step, the token
server has to calculate peer i’s contribution during time
interval t
i;p
. Here, the number of tokens reported by peer
i, r
i;p
, is regarded as the peer’s income, and the number
of tokens generated by peer i, s
i;p
, is considered as the
peer’s spending. We define the peer’s contribution, c
i;p
, as
the difference between r
i;p
and s
i;p
normalized by time,
as given in Eq. (1).
c
i;p
=
r
i;p
¡s
i;p
t
i;p
(1)
Before describing the second step, we define f
i;p
, the
ratio of the advertisement time length to the time length
of streaming content. For instance, in Fig. 3, f
i;p
is the
ratio of a
i;p
to t
i;p
. In the second step, the token server
determines the value of f
i;p
based on c
i;p
calculated in
the first step. Intuitively, the value of f
i;p
is inversely
proportional to c
i;p
. Therefore, there are many functions
which can be used to determine the value of f
i;p
, e.g.,
exponential, linear, and logarithm functions. The choice
of function depends on how “quickly” the system would
like to “reward” peer contributions, e.g., if an exponential
function is used, the value of f
i;p
would decrease quickly
as a peer’s contribution increases. In our system, we choose
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 maximum values
off
i;p
, which are described next.) Intuitively, if a peer is a
free-rider who does not contribute resources, its resource
contribution is¡s
i;p
=t
i;p
, as derived by Eq. (1). Then, its
f
i;p
is set to the maximum value, Max(f), as there are
penalties for free-riding. Otherwise, a peer’sf
i;p
decreases
as its resource contribution increases. If a peer’s c
i;p
is
equal to 0, its f
i;p
is set to the default value, Def(f),
whereas if a peer’sc
i;p
exceeds a threshold,¸, itsf
i;p
is set
to the minimum value,Min(f). In our experiments we use
Min(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. The definition of f
i;p
is given in Eq. (2),
with a corresponding depiction in Fig. 4.
f
i;p
=
8
>
>
>
>
<
>
>
>
>
:
Max(f)¡Def(f)
¡s
i;p
t
i;p
¤c
i;p
+Def(f) , if c
i;p
<0
Min(f)¡Def(f)
¸
¤c
i;p
+Def(f)
, if 0·c
i;p
<¸
Min(f) , if ¸·c
i;p
(2)
Finally, after the token server computes f
i;p
of each
peer, it calculates the amount of advertisement, a
i;p
, for
each peer i as:
a
i;p
=f
i;p
¤t
i;p
(3)
Then, the token server sends each peer a message with
its a
i;p
. After a peer receives this message, it starts to
display advertisements kept in local cache based on its
a
i;p
. Furthermore, the token server also keeps each a
i;p
of
each peer. Because the token server has information about
when a peer joins the system, itst
i;p
, and itsa
i;p
, the token
server knows each peer’s schedule. Then, the token server
calculates a peer’s contribution based on its schedule.
In addition, the token server reports the average value
of f
i;p
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 define f as the proportion of advertisements
to content. In our system, the streaming server chooses
the average value of f
i;p
as f.
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 (of reporting
tokens) to the token server, particularly the amount of
computation needed to perform decryption (as each token
is signed by its generator to prevent malicious users from
generating fake tokens). We depict the token reporting
packet structure of the two schemes in Fig. 2. The two
structures are similar - both include serial number, times-
tamp, generator’s ID, and receiver’s ID. The difference
is that in the reusing scheme, 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 gives the
“number of tokens”, as depicted in Fig. 2. We note that,
in the reuse token scheme, 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 peer i sends peer j a packet which indicates 5 tokens,
and the packet has been encrypted 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 packets
between peers. In Section III, we compare the overhead
and corresponding performance of the two schemes.
B. Server Token Generating Scheme
We now present the second token generation scheme,
namely the server token generating scheme. In this 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. 3. The number of tokens
sent is sufficient 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. At the
end of each content interval, a peer can use tokens to
delete advertisements in the local cache. Therefore, the
amount ofa
i;p
at peeri depends on how much resources it
contributes during t
i;p
. If peer i contributes more resource
during a content interval, t
i;p
, it has more tokens to delete
advertisements at the end of t
i;p
.
We, now, describe how to determine the amount of
advertisements a peer has to watch, a
i;p
. Let L denote
the time length of advertisements in a peer’s local cache,
and N denote the number of tokens the token server
sends to this peer for each content interval. In our system,
each content interval, t
i;p
, is the same for a peer, and the
Min(f)
Def(f)
Max(f)
-s
i,p
/t
i,p
0 λ
f
i,p
c
i,p
Fig. 4. The function used by
the token server to calculate
f
i;p
.
γ
1
0
g
i,p
T
i,p
Fig. 5. An example ofg
i;p
.
0
500
1000
1500
2000
2500
0:00 6:00 12:00 18:00 24:00
Number of peers
Time
Fig. 6. Population of peers
viewing streaming in the
PPLive system
number of tokens, N, in each interval is also the same.
Let T
i;p
denote the number of tokens peer i has at the end
of t
i;p
. We define g
i;p
to be the ratio of the amount of
advertisement a peer i watches to L, as defined in Eq. (4),
where ¹ and ° are parameters controlled by the service
provider.
g
i;p
=maxf
N¡
T
i;p
¹
N
;°g;0·°·1 (4)
Specifically, ¹ is used to control how much adver-
tisement a peer can delete from local cache at the end
of each content interval, and ° is used to control the
minimum time length of advertisements that a peer has
to view. (The service provider may ask peers to view
some minimum amount of advertisements, regardless of
resource contribution, and receive revenue from displaying
advertisements.) Fig. 5 depicts an example g
i;p
. If a peer
is a free-rider, its T
i;p
is 0, and its g
i;p
is 1, as derived
by Eq. (4). Therefore, it has to watch all advertisements.
Otherwise, the value of g
i;p
decreases as a peer increases
its resource contribution.
At the end of t
i;p
, the amount of advertisement a peer
i watches, a
i;p
, is derived by Eq. (5),
a
i;p
=L¤g
i;p
(5)
C. Discussion
In the server token generating scheme, the token server
is responsible for sending tokens for peers, but not for cal-
culating peers’ contributions. Therefore, the token server
does not receive tokens from peers. In the peers token
generating scheme, a peer has to reuse received token
to reduce overhead at the token server. However, in the
server token generating scheme, the token server does not
experience such overhead. The main overhead at the token
server in the server token generating scheme is due to the
token distribution. To reduce overhead, the token server
can send tokens using a staggered schedule, rather than
sending tokens to all peers at once.
Although overhead of the server token generating
scheme is less than that of the peers token generating
scheme, determining advertisement distribution is an issue
for the server token generating scheme. In the peers token
generating scheme, tokens are reported to the token server.
Therefore, the token server has information about peers’
contributions. Based on this information, the token server
computes the average of f
i;p
and sends this information
to the streaming server. Then, the streaming server can
control the advertisement distribution based on the aver-
age f
i;p
. However, the token server does not have such
information in the server token generating scheme because
g
i;p
is determined at the peers’ end. One possible way to
overcome this is to require a peer to report itsg
i;p
periodi-
cally. However, the method is contrary to the original goal
of using tokens because malicious peer can report incorrect
information. In order to filter such incorrect information,
the token server may use the median of g
i;p
instead of
using the average g
i;p
. However, this method can protect
the system only when there relatively few malicious peers.
III. . Evaluation
In this section, we develop a simulator to evaluate
the two proposed token-based schemes, where we use
traces to simulate peer dynamics. The traces are available
from the PPLive Project at [3], collected from the PPLive
streaming system. 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. 6 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 II, which corresponds
to measurements in [6]. Because peers typically do not
Total upload bandwidth (kbps) 256 384 512 768 1024 2048
Distribution(%) 12 40 31 4 7 6
TABLE II. Uploading bandwidth distribution
parameter default value
k 10
n 10
± 500kb
t
i;p
10min
Max(f) 1
Def(f) 0.3
Min(f) 0.1
¹ 2
° 0.1
TABLE III. Default value of parameters
contribute all of their uploading capacity, by default (i.e.,
unless otherwise stated) we begin 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 [7], most of video rates in PPLive system are
between 250 kbps and 400 kbps; thus, in our simulations,
the video rates of streaming content is 300 kbps. The
number of substreams, k = 10, which is the same as in
[13], i.e., the video is divided into 10 substreams, each
of 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 note that we do not consider peer selection algorithms
here since video quality is not the focus of this work.)
In our token-based system, the default amount of data
a peer can download from its neighbor when paying
one token, ±, is 500kb. Each peer pays its neighbors
tokens every 30 seconds. Moreover, the default value of
content interval, t
i;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 we follows, we also vary
the values of ± and t
i;p
(as detailed below). Table III
summarizes the default parameter values.
A. Peers Token Generating Scheme
We now evaluate our peers token generating scheme. In
our simulations, we need to set the maximum, default, and
minimum values of f
i;p
. We set Max(f) = 1. The time
length of advertisement a peer views does not be 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) and Min(f) to 0.3
and 0.1, respectively. We base these on statistics found in
[21], which show that from 1952 to 2010, the average of
f
i;p
of TV programs increased from 0.15 to o.47. Because
service providers of P2P streaming systems may provide
less advertisements than TV , to attract users, we believe
these are reasonable settings of Def(f) and Min(f).
We also set ¸ to s
i;p
=t
i;p
- that is, if a peer’s reported
tokens are more than twice of its generated tokens (derived
from Eq. (1)), its f
i;p
= 0:1. Since, the ratio of average
uploading bandwidth to streaming rate is less than 2 (in
this work), we believe this is a reasonable threshold setting.
We now illustrate that our system can differentiate
peers, using the amount of advertisements they view,
based on their resource contributions. Fig. 7 demonstrates
the average of f
i;p
for different peer classes. It shows
that the average of f
i;p
decreases as a peer’s contribution
increases. Since the uploading rate of a peer in the
first three classes is less than its downloading rate, its
f
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 increase a peer’s
uploading rate from 60% of total uploading capacity to
70% and 80%. The trends off
i;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 of f
i;p
in Fig. 8. This figure indicates that the average of f
i;p
decreases about 27.8% when peer increases its uploading
rate from 60% to 80% of the capacity. This indicates that
we can use advertisements as incentives in P2P streaming
systems, i.e., in order to view fewer advertisements, a
peer needs to contribute more.
1) Reuse v.s. Non-reuse: We now focus on reuse vs.
non-reuse based schemes. In the above experiments, peers
were allowed to reuse received tokens. As noted earlier,
the main advantage of reusing tokens is to reduce overhead
of the token server. Since each token has been encrypted
by its generator, there is significant overhead involved in
the token server decrypting tokens; hence, the motivation
for token re-use in our system. Now, recall that in the
non-reuse scheme, after a peer receives tokens from its
0
0.2
0.4
0.6
0.8
1
256 384 512 768 1024 2048
f
i,p
uploading bandwidth (kbps)
Fig. 7. average f
i;p
for peers
with different uploading
bandwidth
0
0.1
0.2
0.3
0.4
0.5
0.6
60 70 80
f
i,p
uploading ratio (%)
Fig. 8. average f
i;p
for peers
with different uploading ratio
0
0.2
0.4
0.6
0.8
1
256 384 512 768 1024 2048
f
i,p
uploading bandwidth (kbps)
reuse
nonreuse
Fig. 9. average f
i;p
for peers
in reuse and non-reuse
schemes
neighbors, it reports these tokens to the token server
immediately, whereas in the reuse scheme, a peer can reuse
received tokens.
Firstly, we compare the f
i;p
of these two schemes. As
depicted in Fig.9, the f
i;p
’s of these schemes are similar.
In the non-reuse scheme, the token server can calculate
the correct contribution of each peer because every token
is reported. Fig.9 indicates that the token server can still
calculate the exact contribution, even when peers reuse
tokens. Therefore, reusing tokens does not affect accuracy
at the token server.
We now focus on the overhead of these two schemes.
We first define the following parameter.
² ®: the average number of packets reported to the
token server by each peer, per minute, during time
interval t
i;p
. The value of ® is derived from Eq. (6).
®=
# of packets
(# of peers)*t
i;p
(6)
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 schemes
under different values of ±. In the non-reuse scheme, ®
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. 2. Fig.10 illustrates that
® decreases in the reuse scheme as ± increases. This
indicates that the reuse scheme reports fewer packets than
the non-reuse scheme when ± is sufficiently large (e.g.,
250kb and 500kb in our experiments). Hence, reusing
tokens can reduce overhead. However, the performance
of the reuse scheme degrades 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 scheme
behaves worse overhead than the non-reuse scheme. Thus,
the value of ± should not be too small; otherwise, peers
would generate too many tokens, thus increasing the token
server’s overhead.
2) Content Interval, t
i;p
: Now, we focus on the effects
of t
i;p
. If the token server chooses a small value of t
i;p
,
then the token server can reflect peers’ behavior better.
However, if t
i;p
is too small, it interrupts peers frequently
to display advertisements, which would not lead to good
service. Thus, we focus on whether choosing different con-
tent intervals,t
i;p
, affects accuracy when calculating peers’
contribution. We also consider overhead under differentt
i;p
values.
We vary t
i;p
from 1 minute to 20 minutes and calculate
f
i;p
under different t
i;p
’s. We use f
i;p
under the 1 minute
setting as our baseline. The results, derived using Eq. (7),
are given in Fig.11. (Here, we focus on the overall system
performance rather than on per class behavior.)
difference=
P
i
jf
i;p
¡f
baseline
i;p
j
P
i
f
baseline
i;p
(7)
When t
i;p
increases, the difference also increases.
By using short t
i;p
, the token server can account for
peers’ contributions in real time. On the other hand, if
the token server updates using longer time intervals, the
results represent peers’ average contributions during t
i;p
.
In addition to t
i;p
, peers’ uploading rate also affects
results. In Fig.12, t
i;p
is fixed at 5 min, and a peer’s
uploading rate changes from 60% of upload capacity to
100%. The results indicate that the difference increases
when a peer increases its uploading rate. When a peer
increases its uploading rate to 100% of the capacity, 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. In
such a case, the difference may increase.
We now consider the token server’s overhead under
different t
i;p
’s. We depict ®, the average number of re-
ported tokens, in Fig.13(a). In addition, we define ¯ as the
average number of times each token has been reused, with
0
5
10
15
20
25
30
100 250 500
α
δ (kb)
reuse
nonreuse
Fig. 10. The value of ® under
different±
0
0.2
0.4
0.6
0.8
1
1.2
2 5 10 20
difference (%)
t
i,p
(min)
Fig. 11. The average differ-
ence between f
i;p
under dif-
ferentt
i;p
0
0.5
1
1.5
2
2.5
3
3.5
60 80 100
difference (%)
uploading ratio (%)
Fig. 12. The average differ-
ence of f
i;p
when peer’s up-
loading ratio changes from
60% to 100%,t
i;p
= 10 min
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
Fig. 13. The overhead in token server.
0
0.1
0.2
0.3
0.4
0.5
0.6
Min(f) Max(f) Avg(f)
surplus
f
Fig. 14. The average of
surplus by using differentf
results depicted in Fig.13(b). Fig.13 demonstrates 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 when t
i;p
is longer.
3) Advertisement Distribution: Recall that in our sys-
tem, after peers download advertisements, advertisements
are kept in the local cache. If the amount of downloaded
advertisement 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 adver-
tisement data causes network overhead and results in some
useless advertisements being downloaded by peers. How-
ever, distributing too little advertisement content results
in peers viewing a lot of repeated advertisements. This
situation may not be satisfactory for a service provider as
their profit might depend on how often a particular adver-
tisement is viewed. We now consider simple strategies of
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 proportion of advertisement which is not
viewed relative to all of downloaded advertisement;
it is given by Eq. (8) where f is the proportion of
advertisement to streamed media content and f
i;p
is
based on a peer’s contribution.
surplus=
P
i
[max(f;f
i;p
)¡f
i;p
]
P
i
f
(8)
² repeat: the proportion of repeated advertisement to
all of downloaded advertisement, as given by Eq. (9)
repeat=
P
i
[f
i;p
¡min(f;f
i;p
)]
P
i
f
(9)
We use three different values of f: Min(f), Max(f),
and the average of f
i;p
, Avg(f). Specifically, Avg(f) is
calculated by the token server. Based on our experiments,
the average of surplus and repeat are depicted in Fig.14
and Fig.15, respectively.
The results indicate that usingMin(f) asf causes less
network overhead, with no surplus advertisements. How-
ever, 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 advertisement content.
Fig.14 demonstrates that the average surplus advertisement
is more than 50% of all downloaded advertisement. One
approach to finding a balance between these two metrics,
is to use Avg(f). Our results indicate that the average of
surplus and repeat (when using Avg(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.
B. Server Token Generating Scheme
We now focus on evaluating the server token generating
scheme. Recall that, in this scheme, tokens are generated
by the token server, where it sends peers tokens at the begin
of t
i;p
. The amount of tokens sent is sufficient for peers
to download entire streaming media content. Therefore, a
peer does not need to reuse tokens. When a peer receives
tokens from its neighbors, these tokens are kept, and that
peer can then use received tokens to delete advertisement
at end of every period. (Refer to Section II for details). In
the experiments that follow, we sett
i;p
to 10 min, which is
similar to a content interval of TV programs. In addition,
we set ¹ and ° to 2 and 0.1, respectively. Recall that °
is the minimum proportion of advertisements that a peer
has to view. With ¹ set to 2, a peer’s g
i;p
is minimum if
its resource contribution is more than twice of its resource
consumption. The settings are the same as those used in the
evaluation of the peer token generation scheme (above).
The results, as depicted in Fig.16, indicate that peers
with different uploading rates view different amounts of
advertisements. That is, the scheme provides appropriate
incentives - if peer would like to view fewer advertise-
ments, it needs to contribute more upload capacity. The
trends ofg
i;p
for different peer classes, when the uploading
capacity is 70% or 80% (of the available capacity) are
similar to those when the uploading capacity is 60%.
Therefore, we only show the average of g
i;p
, as depicted
in Fig.17. Here, we can observe that as peers increase
their uploading rate from 60% to 80%, the amount of
advertisement reduces by about 19%. Again, the results
of both schemes demonstrate that advertisement could be
used as incentive in P2P streaming systems.
C. Discussion
Our experiments uses single-layer streaming. However,
our token-based schemes can be extended to multi-layer-
based streaming. Briefly, in the peers token generating
scheme, a peer who has low uploading bandwidth can just
download the base layer and generate fewer tokens. A peer
with high upload bandwidth can download more enhanced
layers and pay more tokens. In the server token generating
scheme, the token server sends peers tokens. Although the
number of tokens is sufficient to download all streaming
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, i.e., it can have more tokens
for deleting advertisement at the end of period. The usage
depends on a peer’s preference. If a peer prefers higher
quality, it can use the tokens to obtain enhanced layers and
view more advertisement. Otherwise, a peer can choose
lower quality streaming and view fewer advertisements.
IV . . Related Work
Since P2P streaming services have become popular,
there has been a number of efforts focusing on measure-
ment and analysis of P2P streaming systems, e.g., as in
[7, 9, 24]. For instance, [7] and [24] both focus on the
PPLive system [2], where [7] characterizes user behavior
and traffic profiles, while [24] indicates characteristics of
the PPLive system that are different from those of P2P
file-sharing systems. In [9] the authors focus on the Cool-
streaming system and discuss various associated issues,
including highly skewed resource distribution, excessive
start-up time, and high failure rates during flash crowds.
These works demonstrate several characteristics 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, [2, 4, 5, 27], the architectures of these
systems are not open. Therefore, a number of other design
efforts can be found in the literature, e.g., [19, 25].
For instance, [19] proposes an unstructured, mesh-based
system and indicates that in such systems, the tit-for-
tat mechanism can result in reasonable streaming perfor-
mance. In [25], the authors investigate a framework for
multi-channel P2P streaming systems, which can address
two problems, excessively long channel switching delays
and poor performance to 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., incentives) are closer to
ours. A number of efforts have considered this problem,
from a variety of perspectives, e.g., [8, 11–13, 17, 18, 20].
For instance, [11] and [12] propose layered coding/MDC
schemes with a tit-for-tat type strategy. The schemes use
video quality as an incentive for peers to increase their
0
0.5
1
1.5
2
2.5
Min(f) Max(f) Avg(f)
repeat
f
Fig. 15. The average of repeat
by using differentf
0
0.2
0.4
0.6
0.8
1
256 384 512 768 1024 2048
g
i,p
uploading bandwidth (kbps)
Fig. 16. average g(c
i
) for
peers with different upload-
ing bandwidth
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
60 70 80
g
i,p
uploading ratio (%)
Fig. 17. average g(c
i
) for
peers with different upload-
ing ratio
upload rates. In [8], the authors design an unstructured
protocol that can reduce 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 [20], the authors address
two main problems in tree-based systems and propose
an unstructured swarm overlay system. A credit-based
incentive scheme is adopted in order to fully utilize upload
bandwidth. In [18] the authors study the effects of a
local pairwise incentive mechanism and focus on resource
availability and the average quality of paths. The work in
[17] 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 Token Stealing), based on an Iterated
Prisoner’s Dilemma, is proposed. Lastly, [13] 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 streaming 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 quality, 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 III-C, a peer
can choose different levels of media quality and different
amounts of advertisement, based on its needs. That is,
our schemes can be combined with other related efforts -
e.g., system developers can provide streamed media quality
and fewer advertisements 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 in the context of
our system.
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 [10, 16, 23, 26]. Most of these
efforts focus on credit type systems or micro-payment type
systems for P2P service, based on token-based schemes.
In these systems, peers can exchange tokens, as virtual
currency, to receive resources or service. For instance, [16]
discusses two common incentive methods, reputation and
payment protocols, which share some common character-
istics. Specifically, a general protocol is discussed (termed,
stamp trading), that has properties of the two methods
and can satisfy trust and token-compatibility requirements.
In [26], the authors design a micro-payment system for
P2P applications, while [23] uses self-issued tokens for
accounting in a Grid computing type of a system. In [10],
the authors design a decentralized token-based accounting
scheme, where token are regarded as 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. However, our main purpose in utilizing tokens is
to create a mechanism for accounting for peers’ contribu-
tions.
V . Conclusions
In this paper, we proposed an incentive mechanism,
in the context of P2P streaming systems, for peers to
contribute their upload resources. 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 resources. Our framework design includes two
token-based schemes, which help avoid malicious peer
behavior, i.e., reporting of fake contributions. We discuss
several properties of our token-based schemes, including
token reuse, update period, and advertisement distribution.
Our experimental results provide guidelines and intuition
for the various parameter settings of our framework. Our
technique is orthogonal to earlier efforts in the literature,
using media quality as an incentive. Thus, the two types
of approaches can potentially be combined in one system.
References
[1] BitTorrent. http://www.bittorrent.com/.
[2] PPLive. http://www.pplive.com/.
[3] PPLive Project.
http://cairo.cs.uiuc.edu/ longvu2/pplive.html.
[4] PPStream. http://www.ppstream.com/.
[5] TVUPlayer. http://www.tvunetworks.com/.
[6] M. Dischinger, A. Haeberlen, K. P. Gummadi, and
S. Saroiu. Characterizing Residential Broadband
Networks. In Proceedings of the 7th ACM SIGCOMM
conference on Internet measurement, 2007.
[7] X. Hei, C. Liang, J. Liang, Y . Liu, and K. W. Ross.
Insights into pplive: A measurement study of a large-
scale p2p iptv system. In Proc. of IPTV Workshop,
International World Wide Web Conference, 2006.
[8] P. K. Hoong and H. Matsuo. Push-pull incentive-
based p2p live media streaming system. WTOC, 7(2),
2008.
[9] B. Li, S. Xie, G. Y . Keung, J. Liu, I. Stoica, H. Zhang,
and X. Zhang. An empirical study of the coolstream-
ing+ system. IEEE Journal on Selected Areas in
Communications, 25(9), 2007.
[10] N. Liebau, O. Heckmann, A. Kovacevic, A. Mauthe,
and R. Steinmetz. Charging in peer-to-peer systems
based on a token accounting system. In ICQT, 2006.
[11] Z. Liu, Y . Shen, S. S. Panwar, K. W. Ross, and
Y . Wang. P2p video live streaming with mdc:
Providing incentives for redistribution. In ICME,
2007.
[12] Z. Liu, Y . Shen, S. S. Panwar, K. W. Ross, and
Y . Wang. Using layered video to provide incentives
in p2p live streaming. In P2P-TV, 2007.
[13] Z. Liu, Y . Shen, K. W. Ross, S. S. Panwar, and
Y . Wang. Substream trading: Towards an open p2p
live streaming system. In ICNP, 2008.
[14] Z. Liu, Y . Shen, K. W. Ross, S. S. Panwar, and
Y . Wang. Layerp2p: using layered video chunks in
p2p live streaming. IEEE Transactions on Multime-
dia, 11(7), 2009.
[15] J. J. D. Mol, D. H. J. Epema, and H. J. Sips. The
orchard algorithm: P2p multicasting without free-
riding. In Proceedings of the Sixth IEEE International
Conference on Peer-to-Peer Computing, 2006.
[16] T. Moreton and A. Twigg. Trading in trust, tokens,
and stamps. In the First Workshop on Economics of
Peer-to-Peer Systems, 2003.
[17] V . Pai and A. E. Mohr. Improving robustness of peer-
to-peer streaming with incentives. In Proceedings of
the First Workshop on the Economics of Networked
Systems, 2006.
[18] F. Pianese and D. Perino. Resource and locality
awareness in an incentive-based p2p live streaming
system. In P2P-TV. ACM, 2007.
[19] F. Pianese, D. Perino, J. Keller, and E. W. Biersack.
Pulse: An adaptive, incentive-based, unstructured p2p
live streaming system. IEEE Transactions on Multi-
media, 9(8), 2007.
[20] T. Qiu, I. Nikolaidis, and F. Li. On the design of
incentive-aware p2p streaming. Journal of Internet
Engineering, 1, 2007.
[21] W. Schmidt. How Much TV Commercial
Length has Grown over the Years.
http://www.waynesthisandthat.com/commerciallength.htm.
[22] T. Silverston, O. Fourmaux, and J. Crowcroft. To-
wards an incentive mechanism for peer-to-peer mul-
timedia live streaming systems. In International
Conference on Peer-to-Peer Computing, 2008.
[23] W. Thigpen, T. J. Hacker, L. F. Mcginnis, and B. D.
Athey. Athey: Distributed accounting on the grid.
In the 6th Joint Conference on Information Sciences,
2002.
[24] L. Vu, I. Gupta, J. Liang, and K. Nahrstedt. Measure-
ment and modeling of a large-scale overlay for mul-
timedia streaming. In The International Conference
on Heterogeneous Networking for Quality, Reliability,
Security and Robustness Workshops, 2007.
[25] D. Wu, C. Liang, Y . Liu, and K. Ross. View-upload
decoupling: A redesign of multi-channel p2p video
systems. In IEEE INFOCOM, 2009.
[26] B. Yang and H. Garcia-Molina. Ppay: micropayments
for peer-to-peer systems. In ACM conference on
Computer and communications security, 2003.
[27] X. Zhang, J. Liu, B. Li, and T. shing Peter Yum.
Coolstreaming/donet: A data-driven overlay network
for peer-to-peer live media streaming. In IEEE
Infocom, 2005.
Linked assets
Computer Science Technical Report Archive
Conceptually similar
PDF
USC Computer Science Technical Reports, no. 924 (2012)
PDF
USC Computer Science Technical Reports, no. 913 (2009)
PDF
USC Computer Science Technical Reports, no. 904 (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. 914 (2010)
PDF
USC Computer Science Technical Reports, no. 920 (2011)
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. 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. 888 (2007)
PDF
USC Computer Science Technical Reports, no. 834 (2004)
PDF
USC Computer Science Technical Reports, no. 894 (2008)
PDF
USC Computer Science Technical Reports, no. 923 (2012)
PDF
USC Computer Science Technical Reports, no. 871 (2005)
PDF
USC Computer Science Technical Reports, no. 870 (2005)
PDF
USC Computer Science Technical Reports, no. 578 (1994)
Description
Bo-Chun Wang, Alix L.H. Chow, Leana Golubchik. "P2P streaming systems: 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. 919 (2011).
Asset Metadata
Creator
Chow, Alix L.H.
(author),
Golubchik, Leana
(author),
Wang, Bo-Chun
(author)
Core Title
USC Computer Science Technical Reports, no. 919 (2011)
Alternative Title
P2P streaming systems: 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
UC16270733
Identifier
11-919 P2P Streaming Systems a Study on the Use of Advertisements as Incentives (filename)
Legacy Identifier
usc-cstr-11-919
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
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/
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)
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/