1
LayerP2P: Using Layered Video Chunks
in P2P Live Streaming
Zhengye Liu, Yanming Shen, Keith W. Ross, Fellow, IEEE,
Shivendra S. Panwar, Senior Member, IEEE, Yao Wang, Fellow, IEEE,
Abstract—Although there are several successful commercial
deployments of live P2P streaming systems, the current designs
(i) lack incentives for users to contribute bandwidth resources,
(ii) lack adaptation to aggregate bandwidth availability, and
(iii) exhibit poor video quality when bandwidth availability falls
below bandwidth supply. In this paper, we propose, prototype,
deploy and validate LayerP2P, a P2P live streaming system that
addresses all three of these problems. LayerP2P combines layered
video, mesh P2P distribution, and a tit-for-tat-like algorithm, in
a manner such that a peer contributing more upload bandwidth
receives more layers and consequently better video quality. We
implement LayerP2P (including seeds, clients, trackers, and
layered codecs), deploy the prototype in PlanetLab, and perform
extensive experiments. We also examine a wide range of scenarios
using trace-driven simulations. The results show that LayerP2P
has high efficiency, provides differentiated service, adapts to
bandwidth deficient scenarios, and provides protection against
free-riders.
Index Terms—Peer-to-peer streaming, layered video.
I. INTRODUCTION
With the widespread adoption of broadband residential
access, P2P live video streaming has become a popular service
in the Internet. Recently, several P2P live video systems have
been successfully deployed, supporting tens of thousands of
simultaneous users in a single channel, with stream rates
between 300 kbps to 1 Mbps. These systems include Cool-
Streaming [1], PPLive [2], [3], PPStream [4], UUSee [5] and
many more. All of these systems use a chunk-based mesh-pull
design with single-layer video.
Although the success of these P2P live video systems shows
the potential of efficiently broadcasting live video content
to a large number of users in the Internet, P2P live video
streaming is still in its early stages. These systems have several
This work was supported by the National Science Foundation under
Grant No. CNS-0435228 and the New York State Center for Advanced
Technology in Telecommunications (CATT) at Polytechnic Institute of New
York University, Brooklyn, NY, USA.
Z. Liu, S. S. Panwar, and Y. Wang are with the Department of Electrical
and Computer Engineering, Polytechnic Institute of New York University,
Brooklyn, NY 11201 USA (e-mail: zhengye@vision.poly.edu; yao@poly.edu;
panwar@poly.edu).
Y. Shen was with the Department of Electrical and Computer Engineering,
Polytechnic Institute of New York University, Brooklyn, NY 11201 USA.
He is now with Computer Science and Engineering Department at Dalian
University of Technology, China (e-mail: shen@dlut.edu.cn).
K. W. Ross is with the Department of Computer Science and Engineering,
Polytechnic Institute of New York University, Brooklyn, NY 11201 USA (e-
mail: ross@poly.edu).
Copyright (c) 2008 IEEE. Personal use of this material is permitted.
However, permission to use this material for any other purposes must be
obtained from the IEEE by sending a request to pubs-permissions@ieee.org.
critical design problems, limiting their robustness, scalability,
and performance:
• Lack of incentives: Peers have heterogeneous upload
bandwidths and exhibit a wide range of altruistic behavior
for contributing upload bandwidth. In existing P2P live
video systems, peers all receive the same video quality
no matter how much upload bandwidth they contribute to
the system. To build a robust and scalable P2P system,
it is critical to provide incentives to reward peers that
contribute more.
• Lack of adaptation to bandwidth availability: In P2P
live video systems, both the system supply (the aggregate
upload bandwidth of the peers) and the system demand
(the aggregate download rate of the peers) fluctuate.
This long-term bandwidth fluctuation is mainly due to
peer churn. When the system operates in a bandwidth-
deficient regime, where the system supply is less than the
system demand, the user experience will be significantly
degraded.
• Severe degradation of video quality: Packet loss in
P2P streaming is not only caused by transmission loss
(e.g., due to network congestion), but also by the lack
of bandwidth and/or content at the supplying peers. With
single layer video, any lost packet can lead to significant
degradation in decoded video quality, due to spatial-
temporal prediction and entropy coding in the encoded
video. Typically a video is coded into groups of pictures
(GOP) with the first frame of each GOP coded without
referencing previous frames (known as the I-frame) and
all following frames coded with references to previous
frames. A lost packet not only affects the video frame
it belongs to, but also affects the successive frames due
to error propagation. This induces severe video quality
degradation.
In this paper, we propose, prototype, deploy and validate
LayerP2P, a P2P live streaming system that simultaneously
addresses all of the above three problems. LayerP2P applies
layered video on mesh-pull P2P live streaming systems. With
layered coding, a video is coded into layers with nested
dependency: a higher layer refines the video generated by
lower layers. More received layers provide better video quality.
In the past, the coding efficiency of layered coding was
significantly lower than that of single layer coding, which
has hindered its deployment in practical systems. However, in
recent years the coding efficiency of layered video has been
significantly improved. For example, the newly established
2
H.264/SVC (layered coding) achieves a rate-distortion per-
formance comparable with H.264/AVC (single-layer coding),
with the same visual reproduction quality typically achieved
with at most 10% higher bit rate [6]. Real-time systems
with H.264/SVC encoder and decoder have been successfully
implemented [7]. Real-time decoders [8] that support H.264
temporal scalable coding have been made available in the
public domain. With these advances, layered video is ready
for deployment in practical video applications. We will show,
in particular, that it can significantly enhance P2P live video
systems.
LayerP2P has a different design philosophy compared with
the existing P2P live streaming deployments. In LayerP2P,
when the system has abundant bandwidth, where the average
upload bandwidth supply is higher than the full video rate,
every peer can receive all layers of the video and enjoy
excellent quality. However, when the system is in a bandwidth-
deficient state (e.g., due to too many peers with low upload
bandwidth or too many free-riders), so that not all peers can
receive the full video rate, a peer’s received video quality is
commensurate with its upload contribution to the system. The
peers providing high upload contribution receive high video
quality; the peers providing moderate upload contribution
receive lower but still acceptable video quality; while the free-
riders receive at most poor video quality. LayerP2P has the
following key characteristics:
• Built-in incentives: With layered video, more received
video chunks in the order of their importance lead to
higher video quality. LayerP2P exploits this property,
together with a tit-for-tat-like strategy, to provide in-
centives for uploading. Specifically, each peer measures
its download rates from its neighbors, and reciprocates
by providing a larger fraction of its upload rate to the
neighbors from which it is downloading at higher rates.
Using this mechanism, when the system is overloaded
and cannot support all peers with the full video rate, the
video quality a peer receives is commensurate with its
upload contribution. LayerP2P therefore uses the follow-
ing incentive principle: the more a peer contributes, the
better its received video quality.
• Adaptation to available upload bandwidth: LayerP2P
dynamically adapts the system demand to the system sup-
ply. As the system aggregate bandwidth supply evolves
due to peer churn, LayerP2P automatically adjusts video
quality for the individual peers. From the perspective
of the overall system, aggregate bandwidth deficiency, a
nemesis for single-layer designs, is thus largely avoided.
• Graceful video quality degradation: With LayerP2P,
lost packets in an enhancement layer do not affect the
decoding of lower layers. Our proposed chunk requesting
and scheduling schemes give higher priority to more
important layers.
We develop a prototype for LayerP2P, including seed im-
plementation, client implementation, and tracker. Using actual
layered encoded video, we deploy the prototype in PlanetLab
and conduct extensive experiments. To further understand the
system behavior with realistic peer dynamics, we also conduct
trace-driven simulations by using the traces for peer dynamics
from a real-world P2P live streaming system. We compare
LayerP2P with two single-layer P2P live video streaming
systems. Both the experiments with the prototype in PlanetLab
and the trace-driven simulations show that: (i) when the aver-
age system upload bandwidth is higher than the full video rate,
LayerP2P can efficiently use the system resource to provide
good video quality to all peers; (ii) when the average system
upload bandwidth is lower than the full video rate, LayerP2P
provides differentiated services for different peers and also
prevents free-riding. Compared with the corresponding single-
layer video systems, for both scenarios, LayerP2P provides an
improved video quality for cooperative peers.
The remainder of this paper is structured as follows. Sec-
tion II sets the stage for LayerP2P by providing a brief
overview of mesh P2P systems and modern layered video.
Section III presents the design of LayerP2P. In Section IV
and V, we describe our implementation and evaluate its
performance in a PlanetLab deployment. In Section VI, we
evaluate the performance of LayerP2P in a wider range of
scenarios using trace-driven simulations. Section VII describes
related work. We conclude in Section VIII.
II. OVERVIEW OF P2P STREAMING AND VIDEO CODING
Before describing LayerP2P in details, it is beneficial to first
review P2P streaming and modern video encoding.
A. P2P Live Streaming Systems
The chunk-based mesh design is the most popular and
successful design in P2P live streaming today, due to its
robustness to peer dynamics, high network scalability, and
simplicity. Most of the existing P2P live streaming systems
adopt this design.
In a chunk-based mesh-pull delivery architecture for live
video streaming, as shown in Figure 1(a), the source divides
the encoded bit stream into video chunks and then dissemi-
nates the video chunks to a set of randomly selected peers.
When a peer wants to view the video, it obtains a list of peers
currently watching the video. This procedure can be imple-
mented by using a tracker that maintains all peer information,
or with a DHT or gossiping. After obtaining the peer list,
the peer selects several peers as its neighbors and establishes
neighbor relationships with them. A neighbor relationship can
be a real TCP connection between two peers, or simply a
conceptual relationship without a real TCP connection. The
peers in the system are self-organized into a mesh overlay,
as illustrated in Figure 1(b). A peer acts as a supplier when
it sends video chunks to its neighbors, while it acts as a
receiver when it requests video chunks from its neighbors.
As shown in Figure 1(c), each peer caches video chunks
and maintains an exchange window. Typically, the exchange
window includes all chunks between the playback time of
a particular peer t
p
and the video encoding time t
e
at the
video source. Periodically, neighbors exchange buffer maps
with each other, explicitly informing their available chunks in
the exchange windows. A peer carefully schedules its needed
chunks based on the buffer maps and requests them from its
3
(a)
A
C
D E
B
ud
(b)
...
0 Timetetp
1111010110100
(c)
Fig. 1. Architecture of chunk-based mesh-pull systems. (a)Overall architec-
ture; (b)Mesh overlay; (c)Buffer structure and buffer map.
neighbors. After receiving the requests, the neighbors serve the
scheduled chunks to this peer based on some policy (with the
most common practice being first come first serve for single
layer video). In such a chunk-based design, each media chunk
will be explicitly identified, requested, and scheduled.
B. Layered Video
Layered coding encodes a video into multiple layers with
nested dependency: the base layer alone typically provides
an acceptable basic quality, while a higher layer refines the
video generated by lower layers. Layered coding is typically
accomplished by providing multiple versions of a video either
in terms of amplitude resolutions (called quality scalability or
SNR scalability), spatial resolutions (spatial scalability), tem-
poral resolutions (temporal scalability), frequency resolutions
(frequency scalability or data partition), or combinations of
these options.
In recent years, significant advances have been made in
layered coding. H.264/SVC [9], the most recent scalable video
coding standard, supports SNR scalability (coarse granularity
scalability (CGS) and medium granularity scalability (MGS)),
spatial scalability and temporal scalability. It provides the
flexibility to encode a video into a large number (more than
four) of layers. More importantly, coding efficiency of layered
video has been significantly improved in H.264/SVC. Now
H.264/SVC (layered coding) achieves a rate-distortion per-
formance comparable with H.264/AVC (single-layer coding),
with the same visual reproduction quality typically achieved
with at most 10% higher bit rate [6]. The temporal scalable
video coding can achieve an even higher coding efficiency than
single-layer coding. Additionally, the video coding complex-
ity, especially the decoding complexity, is well addressed in
H.264/SVC. In [7], it is reported that a real-time H.264/SVC
encoder and decoder have been successfully implemented, for
different types of scalability. In particular, temporal scalable
video is supported by both H.264/SVC and H.264/AVC due to
its high video coding efficiency. FFmpeg[8] is an open source
codec that can decode H.264 temporal scalable video in real-
time.
...
0 Timetetp
1111010110100
1110110100000
1
L
...
...
Fig. 2. Buffer structure of the layered system.
In LayerP2P, we do not make any assumption about the
format of layered video. Any scalable or layered video coding
scheme (temporal scalability, spatial scalability, SNR scala-
bility, or any combination of them) can be incorporated into
the LayerP2P framework. LayerP2P can work with either a
few or many layers. Importantly, we do not require advanced
rate control and rate partition mechanisms for creating layers,
i.e., each layer can have an arbitrary bit rate. Furthermore, we
do not require a specific GOP structure, video packetization,
error resilience/concealment scheme, etc. As we will see in
Section V, we use FFmpeg as the video decoder with its
default configurations in our implementation, without any
modification. We note that this loose requirement on the video
coder is enabled by the chunk-based requesting and delivery
architecture adopted by LayerP2P.
III. DESIGN PHILOSOPHY
In this section we describe the design of LayerP2P, in-
cluding neighbor establishment, incentive strategy, and video
chunk scheduling algorithms. We highlight how the features
of LayerP2P prevent free-riders.
A. Overview of LayerP2P
LayerP2P uses layered video (instead of single-layer video)
on chunk-based mesh P2P live streaming systems. The video
source encodes a video into L layers and each layer is
sliced into packets, called layer chunks (LCs). These LCs are
distributed over a self-organized mesh overlay, as we describe
subsequently. Similar to the existing single-layer systems (e.g.
PPLive), when a peer joins in the system, it obtains a peer list
from a tracker. The peer then selects a subset of peers from the
list and forms neighbor relationships with them. In our design,
peers categorize their neighbors into different types and treat
them differently.
Unlike the single-layer video systems, in LayerP2P each
peer maintains L buffers, one for each layer, with each buffer
caching the LCs for its layer (see Figure 2). A peer’s buffer
map is a data structure that indicates which LCs it currently
has. Each peer periodically exchanges its buffer map with
its neighbors. Upon learning what LCs its neighbors have, a
peer sends requests for its missing LCs. As discussed below,
the peer carefully prioritizes the requests to maximize its
received video quality. As a supplier, a peer may receive
multiple requests from multiple neighbors. Based on a tit-for-
tat like strategy, the supplier allocates larger fractions of its
upload bandwidth to the neighbors who have higher upload
contributions to the supplier. A peer may have neighbors who
serve it with a low rate because of a lack of bandwidth, a lack
4
of content, or an unwillingness to contribute. To obtain better
neighbors, each peer modifies its neighbors periodically.
B. Neighbor Management
Neighbors are two peers that connect with each other to
exchange data chunks. In our design, each peer classifies
its neighbors into initiators and receptors and treats them
differently. If peer A initiates the neighbor relationship by
actively sending peer B a neighbor establishment message,
then peer A is an initiator for peer B, while peer B is a receptor
for peer A.
In P2P live streaming, each peer should have a sufficient
number of neighbors to maintain the connectivity of the
overlay. But, to limit the overhead, a peer should not have
too many neighbors. Additionally, the system should avoid
completely filling its connection slots, so that newcomers can
get in. In our design, if a peer has less than N
min
neighbors,
it will actively seek new neighbors; if the peer has greater
than N
min
and less than N
max
(N
max
> N
min
) neighbors,
it passively accepts new neighbors, but will not actively seek
new neighbors; if the peer has N
max
neighbors, it will decline
all neighbor establishment requests. In this manner, typically a
peer has less than N
max
but more than N
min
neighbors, which
maintains the connectivity of the overlay, while reserving room
for newcomers. Like BitTorrent, in order to locate a better
neighbor with higher uplink bandwidth and more content, in
our scheme a peer periodically replaces the neighbor with the
least contribution with a new peer.
C. Tit-for-Tat with Layered Video
BitTorrent is a remarkably popular file-distribution technol-
ogy, with millions of users sharing content in hundreds of
thousands of torrents on a daily basis. BitTorrent’s incentive
principle is as follows: a peer will get the file faster if
it contributes more upload bandwidth to the torrent. This
incentivizes users to upgrade their ISP access and/or increase
the maximum upload rates (typically configurable) in their
BitTorrent clients. BitTorrent provides this basic incentive
using the celebrated tit-for-tat algorithm [10], in which peers
trade blocks of content with each other. (Although several
recent studies have shown that the tit-for-tat algorithm is not
sufficient for preventing free-riders or fully incentivizing users
[11], the algorithm has nevertheless been very successful in
practice. If BitTorrent had been designed without a tit-for-tat
algorithm, it almost surely would not have the success that
it enjoys today.) Tit-for-tat effectively creates a differentiated
service at the application layer, providing high-speed uploaders
with short download times and low-speed uploaders with long
download times.
Inspired by BitTorrent’s incentive philosophy, we apply the
tit-for-tat-like strategy on P2P live streaming systems. We
advocate a new incentive principle for live P2P streaming,
namely, peers that upload more see higher quality video.
More specially, in our proposed system, each peer measures
its download rates from its neighbors. A peer reciprocates to
its neighbors by providing a larger fraction of its upload rate
to the neighbors from which it is downloading at the higher
...
k
p
n,k
Probing
Request
Regular
Request
...
Fig. 3. Request queue structure at a supplier.
rates. In this manner, a peer with higher upload contribution is
likely to be rewarded with more LCs, and hence more layers
and better quality. This strategy is implemented through the
supplier side scheduler described below.
D. Supplier Side Scheduler
As a supplier, a peer receives LC requests from multiple
neighbors. The peer must determine which requests should be
served first and how to allocate its available uplink bandwidth
to its neighbors. In our design, a peer will upload more to
the neighbors from which it downloads more. To this end, a
supplier maintains a different request queue for each receiver,
as shown in Figure 3. For a particular receiver, the queue
is first-in-first-out, where the supplier serves the requests in
the order that the requests are received. (In Section III-E,
we provide a refinement of the supplier side scheduler.) The
supplier transmits one requested LC to one receiver at a time.
Each request has a deadline to be served. If the supplier cannot
serve a request before its deadline, it simply removes this
request from the request queue and does not serve this request.
More details about the request deadline will be described in
Sec. III-F.
The supplier determines which receiver should be served
depending on the receiver’s contribution to the supplier. At
any one time, the supplier randomly selects a receiver to serve.
Let p
n,k
denote the probability that peer n selects the receiver
k. p
n,k
is determined as follows:
p
n,k
=
I
n,k
(d
n,k
+ )
P
i∈K
n
I
n,i
(d
n,i
+ )
, (1)
where K
n
is peer n’s set of neighbors, d
n,i
is the rate at which
peer n is receiving from peer i, and is a small positive
number. I
n,i
equals 0 if the request queue of receiver i is
empty, and equals 1 otherwise. ensures that all of peer n’s
neighboring peers will be considered even if its d
n,k
= 0. In
summary, a receiver that uploads more to the supplier has a
higher probability of being served, consuming a larger share
of the supplier’s uplink bandwidth.
Note that supplier always sends an LC as long as one of its
queues is non-empty and if it has surplus upload bandwidth. In
particular, a receiver with a low d
n,i
will be served when the
other receivers do not have outstanding requests. Therefore,
peers with a low upload bandwidth can receive a high video
rate when the system is underloaded.
When two peers, say peer k and n, newly establish a
neighbor relationship, they treat each other as if they have
downloaded from each other in the recent past. But the two
new neighbors treat each other unequally with different initial
download rates. The initiator peer k treats its receptor peer n
5
as if n is providing a large download rate d
l
, and therefore
allocates a large share of upload bandwidth to n. On the other
hand, the receptor peer n treats its initiator peer k as if it has a
small download rate d
s
, and therefore allocates a small share of
upload bandwidth to it. This strategy is similar in spirit to the
“optimistic unchoke” in BitTorrent. The neighbors, especially
the initiators, are generous to each other. A small d
s
prevents
a free-rider from obtaining high download rates by actively
adding a large number of neighbors. This will be described in
more details in Sec. III-F.
E. Receiver Side Scheduler
As a receiver, a peer may have multiple missing LCs, and
for a given LC there may exist multiple neighbors that have
it. The peer needs to determine how to request these LCs to
maximize its received video quality.
In single layer video systems, it has been shown that a
simple random scheduling scheme is sufficient to achieve a
high system throughput (i.e., high usage of available upload
bandwidth of peers) [12], [13]. This scheme works as follows.
Peers request their missing chunks in rounds. In each round of
T seconds, the receiver requests all the chunks that it does not
have but are available at its neighbors. The receiver requests
these missing chunks in a random order without prioritizing
them. For a particular chunk, the receiver randomly selects a
supplier to serve this chunk if it is available from more than
one supplier. The receiver groups all chunk requests scheduled
to a particular supplier into one request message. In the next
round, the receiver schedules the missing chunks which are
newly available in its neighbors, together with the previously
scheduled-but-not-served chunks. To avoid sending duplicated
chunks, at the supplier side, each chunk request has a serving
deadline. If the supplier cannot serve a chunk request within
time T − τ (where τ represents the round-trip delay between
the receiver and the supplier) from when it receives the chunk
request, it simply removes this chunk request from its request
queue.
Although the simple random scheduling scheme just de-
scribed works well for single-layer video, it cannot be di-
rectly applied to layered video. This is because in layered
video systems, a higher downloading rate does not necessarily
translate to a better video quality. A receiver peer needs to
prioritize the LC requests based on their importance for the
reconstructed video. In general, if the available downloading
rate of a receiver is less than the full video rate, it should
only request the LCs from the lower layers such that the
aggregate rate is below its downloading rate. A receiver faces
a dilemma: on the one hand, if it requests too aggressively
for higher layers, the LC requests for lower layers may not
be able to be served before its playback deadline (which is
different from the T − τ deadline in this round); on the other
hand, if it requests too conservatively, it may not fully utilize
the potential bandwidth of its supplier.
To solve this problem, LayerP2P uses a prioritized random
scheduling algorithm tailored for layered video. With such an
algorithm, the requests for different LCs are categorized into
two types, namely, regular requests and probing requests. A
peer expects regular requests to be served on time with high
probability, and expects the probing requests to be served when
the suppliers have surplus upload bandwidth allocated to this
peer. For a particular peer n, the LC requests for the layers
lower than or equal to a threshold l
n
are designated to be
regular requests, while the LC requests for higher layers are
designated to be probing requests. l
n
is determined by the
expected available downloading rate of peer n. Let
u
n,k
=
d
n,k
U
n
P
i∈K
n
d
n,i
, (2)
where u
n,k
is the upload bandwidth allocated from peer n to
peer k. It has been proven [14] that, if each peer performs the
pair-wise proportional bandwidth allocation to its neighbors,
then the available download rate of peer n (denoted as D
n
)
asymptotically equals its upload rate (denoted as U
n
). It is
not difficult to see that the supplier scheduling algorithm in
Section III-D follows the pair-wise proportional bandwidth
allocation, when the system is in the saturated regime, where
each peer always has requests to serve. Thus, we set l
n
to the
largest layer index l for peer n, where R(l) ≤ U
n
≤ R(l + 1)
and R(l) denotes the video rate up to layer l.
The regular requests (for layers 1 to l
n
) are assigned to
different suppliers based on the previously described random
scheduling algorithm for single layer video, without priori-
tization among different layers (from layer 1 to layer l
n
).
The probing requests (for layer l
n+1
to L) are sent to the
suppliers layer by layer, beginning with layer l
n+1
and ending
with layer L. For a particular layer, the probing requests are
scheduled based on the above random scheduling algorithm. In
summary, for each receiver, the regular requests have strictly
higher priority over the probing requests, and the probing
requests from lower layers have higher priority than those
from higher layers. The reason that we do not prioritize the
regular requests by layers is to preserve the randomness of the
requests, thereby increasing the overall system throughput. The
receiver scheduling algorithm is summarized in Algorithm 1.
F. Free-rider Prevention
A free-rider is a peer who intends to enjoy the system’s
services without contributing. As observed in P2P file down-
loading systems, free-riding is a prevalent problem which can
significantly degrade the system performance. LayerP2P has
several features that prevent free-riding. With the pair-wise
proportional bandwidth allocation, a free-rider can only obtain
a small share of upload bandwidth from its neighbors in an
overloaded situation, no matter how many neighbors this peer
has [14]. This limits its download rate and received video
quality. With the periodic neighbor adaptation, a free-rider
experiences unstable neighbor relationships which normally
leads to unstable video quality. After a free-rider is dropped
by its neighbors, it may switch to other new neighbors for
free-riding. However, with the differentiated neighbor types, a
free-rider can only get limited benefit even if it keeps jumping
around. With the extreme setup d
s
= 0, no matter how many
receptors the free-rider actively locate, it will not be served
for free.
