P2P Applications - Peer-to-Peer Computing: Applications, Architecture, Protocols, and Challenges - page 22

as a parent, receives a request from the client, it will continuously push pack-
ets to the client unless the latter decides to drop this partner. This feature is
designed for enhancing the downloading e ciency.
PPStream [PPStream, 2009] is also a highly popular P2P video streaming
application in the Greater China region. It is reported that with around 65
million media streaming clients every month, PPStream's share is roughly
35.1% [Wei and Chen, 2008]. PPStream's design and implementation are also
rather standard. When a client starts, it first contacts a channel list server
node (cached or from a list of well-known bootstrap nodes) to obtain a channel
list. Upon selecting a particular channel to watch, the node then contacts a
corresponding tracker node to obtain a list of peers. It then selects a subset of
such peers to establish connections. Buffer maps are then retrieved from such
peers and the downloading process can begin. After getting enough packets
for the playback buffer, the video player can start while the node continues to
share packets with other peers watching the same channel.
PPLive [PPLive, 2009, Vu et al., 2010] is one of the highly popular mesh-
pull-based P2P video streaming systems. It is reported [Hei et al., 2007a] that
PPLive serves on the order of 3 million daily users on average with over 300
channels at a data rate of around 250 kbps to 400 kbps. The protocols used in
PPLive are observed to be similar to a typical mesh pull system. Performance-
wise, PPLive still has a number of deficiencies [Hei et al., 2007a, Vu et al.,
2010], despite its high popularity. For example, the start-up delay (i.e., the
time duration between the time a user chooses a channel and the time the
video starts) is on the order of 20 seconds for popular channels, and can go up
to a couple of minutes for unpopular channels. Another problem is the high
playback lags among peers. Specifically, due to different buffering progresses
among peers, a peer may view the video that is lagging behind some other
peers. It is found [Hei et al., 2007a] that the lag can be as high as 140 seconds
of video, possibly leading to frustrating user experiences (e.g., imagine the
users are watching a live soccer game). We further discuss the application
properties of PPLive in Section 2.7.
Parvez et al. [Parvez et al., 2008] presented a useful mathematical charac-
terization of P2P video downloading mechanisms based on a simple model. In
the model, a video file is divided into M chunks, encoded at a playback rate of
r. Each peer is capable of making a maximum of U connections for uploading
simultaneously. A peer can also use up to D downloading connections. The
average data rate of each of these connections is C. The number of down-
loading peers and uploading peers are denoted by x and y, respectively. New
downloading peers enter the system at a rate of λ, while chunks-supplying
(i.e., sources) peers stay in the system for a time period of 1/. Because each
new downloading peer becomes a source itself at a rate of (x + y)U C, we have:

dx
dt

= λ−(x + y)U C (2.1)