draft-ietf-ppsp-survey-01.txt   draft-ietf-ppsp-survey-02.txt 
skipping to change at page 1, line 19 skipping to change at page 1, line 19
China Mobile China Mobile
J. Lei J. Lei
University of Goettingen University of Goettingen
Gonzalo. Camarillo Gonzalo. Camarillo
Ericsson Ericsson
Yong. Liu Yong. Liu
Polytechnic University Polytechnic University
Delfin. Montuno Delfin. Montuno
Lei. Xie Lei. Xie
Huawei Huawei
March 11, 2011 July 05, 2011
Survey of P2P Streaming Applications Survey of P2P Streaming Applications
draft-ietf-ppsp-survey-01 draft-ietf-ppsp-survey-02
Abstract Abstract
This document presents a survey of popular Peer-to-Peer streaming This document surveys a number of popular Peer-to-Peer streaming
applications on the Internet. We focus on the Architecture and Peer applications on the Internet. The Architecture and Peer
Protocol/Tracker Signaling Protocol description in the presentation, Protocol/Tracker Signaling Protocol description is our main focus.,
and study a selection of well-known P2P streaming systems, including We study well-known P2P streaming systems, including Joost, PPlive,
Joost, PPlive, andother popular existing systems. Through the and other popular existing systems, and we summarize a common P2P
survey, we summarize a common P2P streaming process model and the streaming process model and its correspondent signaling process for
correspondent signaling process for P2P Streaming Protocol use in the P2P Streaming Protocol standardization effort.
standardization.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 4, line 8 skipping to change at page 4, line 8
3.3.1. New Coolstreaming . . . . . . . . . . . . . . . . . . 26 3.3.1. New Coolstreaming . . . . . . . . . . . . . . . . . . 26
4. A common P2P Streaming Process Model . . . . . . . . . . . . . 29 4. A common P2P Streaming Process Model . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
7. Informative References . . . . . . . . . . . . . . . . . . . . 30 7. Informative References . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Toward standardizing the signaling protocols used in today's Peer-to- Toward standardizing the signaling protocols used in today's Peer-to-
Peer (P2P) streaming applications, we surveyed several popular P2P Peer (P2P) streaming applications, we survey several popular P2P
streaming systems regarding their architectures and signaling streaming systems regarding their architectures and signaling
protocols between peers, as well as, between peers and trackers. The protocols between peers, as well as, between peers and trackers. The
studied P2P streaming systems, running worldwide or domestically, studied P2P streaming systems, operating worldwide or domestically,
include such as PPLive, Joost, Cybersky-TV, and Octoshape. This include PPLive, Joost, and Octoshape. As this
document does not intend to cover all design options of P2P streaming document is not intended to cover all design options of P2P streaming
applications. Instead, we choose a representative set of applications, we choose a representative set of
applications and focus on the respective signaling characteristics of applications and focus on each of their respective signaling
each kind. Through the survey, we generalize a common streaming characteristics. Through the survey, we propose a generalized common
process model from those P2P streaming systems, and summarize the streaming process model derived from those P2P streaming systems, and
companion signaling process as the base for P2P Streaming Protocol summarize the companion signaling process as the basis for P2P
(PPSP) standardization. Streaming Protocol (PPSP) standardization.
2. Terminologies and concepts 2. Terminologies and concepts
Chunk: A chunk is a basic unit of partitioned streaming media, which Chunk: A chunk is a basic unit of partitioned streaming media, which
is used by a peer for the purpose of storage, advertisement and is used by a peer for the purpose of storage, advertisement and
exchange among peers [Sigcomm:P2P streaming]. exchange among peers [Sigcomm:P2P streaming].
Content Distribution Network (CDN) node: A CDN node refers to a Content Distribution Network (CDN) node: A CDN node refers to a
network entity that usually is deployed at the network edge to store network entity that usually is deployed at the network edge to store
content provided by the original servers, and serves content to the content provided by the original servers, and serves content to the
skipping to change at page 5, line 21 skipping to change at page 5, line 21
service which maintains the lists of peers/PPSP peers storing chunks service which maintains the lists of peers/PPSP peers storing chunks
for a specific channel or streaming file, and answers queries from for a specific channel or streaming file, and answers queries from
peers/PPSP peers. peers/PPSP peers.
Video-on-demand (VoD): A kind of application that allows users to Video-on-demand (VoD): A kind of application that allows users to
select and watch video content on demand select and watch video content on demand
3. Survey of P2P streaming system 3. Survey of P2P streaming system
In this section, we summarize some existing P2P streaming systems. In this section, we summarize some existing P2P streaming systems.
The construction techniques used in these systems can be largely The construction techniques used in these systems can be
classified into two categories: tree-based and mesh-based structures. classified mainly into three categories: tree-based, mesh-based,
and hybrid structures.
Tree-based structure: Group members self-organize into a tree Tree-based structure: Group members self-organize into a tree
structure, based on which group management and data delivery is structure, based on which group management and data delivery are
performed. Such structure and push-based content delivery have small performed. Such structure with push-based content delivery has small
maintenance cost and good scalability and low delay in retrieving the maintenance cost, good scalability and low delay in retrieving the
content(associated with startup delay) and can be easily implemented. content(associated with startup delay) and can be easily implemented.
However, it may result in low bandwidth usage and less reliability. However, it may result in low bandwidth usage and less reliability.
Mesh-based structure: In contrast to tree-based structure, a mesh Mesh-based structure: In contrast to tree-based structure, a mesh
uses multiple links between any two nodes. Thus, the reliability of uses multiple links between any two nodes. Thus, the reliability of
data transmission is relatively high. Besides, multiple links data transmission is relatively high. Besides, multiple links
results in high bandwidth usage. Nevertheless, the cost of result in high bandwidth usage. Nevertheless, the maintenance cost
maintaining such mesh is much larger than that of a tree, and pull- is much larger than that of a tree, and the pull-based content
based content delivery lead to high overhead associated each video delivery leads to high overhead associated with each video
block transmission, in particular the delay in retrieving the block transmission, particularly, the delay in retrieving the
content. content.
Hybrid structure: Combine tree-based and mesh-based structure, Hybrid structure: Has a combined tree-based and mesh-based structure
combine pull-based and push-based content delivery to utilize the and uses both pull-based and push-based content delivery to take
advantages of two structures. It has high reliability as much as advantages of the two structures. Compared to the mesh-based structure,
mesh-based structure, lower delay than mesh-based structure, lower it has an equally high reliability and topology maintenance cost but
overhead associated each video block transmission and high topology a much lower delay and overhead associated each video block
maintenance cost as much as mesh-based structure. transmission.
3.1. Mesh-based P2P streaming systems 3.1. Mesh-based P2P streaming systems
3.1.1. Joost 3.1.1. Joost
Joost announced to give up P2P technology on its desktop version last Joost announced to give up P2P technology on its desktop version last
year, though it introduced a flash version for browsers and iPhone year, though it introduced a flash version for browsers and iPhone
application. The key reason why Joost shut down its desktop version application. The key reason why Joost shut down its desktop version
is probably the legal issues of provided media content. However, as is probably the legal issues of provided media content. However, as
one of the most popular P2P VoD application in the past years, it's one of the most popular P2P VoD application in the past years, it's
worthwhile to understand how Joost works. The peer management and worthwhile to understand how Joost works. The peer management and
skipping to change at page 6, line 23 skipping to change at page 6, line 23
The three key components of Joost are servers, super nodes and peers. The three key components of Joost are servers, super nodes and peers.
There are five types of servers: Tracker server, Version server, There are five types of servers: Tracker server, Version server,
Backend server, Content server and Graphics server. The architecture Backend server, Content server and Graphics server. The architecture
of Joost system is shown in Figure 1. of Joost system is shown in Figure 1.
First, we introduce the functionalities of Joost's key components First, we introduce the functionalities of Joost's key components
through three basic phases. Then we will discuss the Peer protocol through three basic phases. Then we will discuss the Peer protocol
and Tracker protocol of Joost. and Tracker protocol of Joost.
Installation: Backend server is involved in the installation phase. Installation: In the installation phase, Backend server provides peer
Backend server provides peer with an initial channel list in a SQLite with an initial channel list in a SQLite file. No other parameters,
file. No other parameters, such as local cache, node ID, or such as local cache, node ID, or listening port, are configured in
listening port, are configured in this file. this file.
Bootstrapping: In case of a newcomer, Tracker server provides several Bootstrapping: In case of a newcomer, Tracker server provides several
super node addresses and possibly some content server addresses. super node addresses and possibly some content server addresses.
Then the peer connects Version server for the latest software Then the peer connects to Version server for the latest software
version. Later, the peer starts to connect some super nodes to version. Later, the peer connects to some super nodes to
obtain the list of other available peers and begins streaming video obtain the list of other available peers through which streaming video
contents. Different from Skype [skype], super nodes in Joost only begins. Unlike Skype [skype], super nodes in Joost only
deal with control and peer management traffic. They do not relay/ deal with control and peer management traffic. They do not relay/
forward any media data. forward any media data.
.
Channel switching: Super nodes are responsible for redirecting Channel switching: Super nodes are responsible for redirecting
clients to content server or peers. clients to content server or peers.
Peers communicate with servers over HTTP/HTTPs and with super nodes/ Peers communicate with servers over HTTP/HTTPs and with super nodes/
other peers over UDP. other peers over UDP.
Tracker Protocol: Because super nodes here are responsible for Tracker Protocol: Because super nodes here are responsible only for
providing the peerlist/content servers to peers, protocol used providing the peerlist/content servers to peers, the protocol used
between tracker server and peers is rather simple. Peers get the between tracker server and peers is rather simple. Peers get the
addresses of super nodes and content servers from Tracker Server over addresses of super nodes and content servers from Tracker Server over
HTTP. After that, Tracker sever will not appear in any stage, e.g. HTTP. After that, Tracker server will not appear in any other stages,
channel switching, VoD interaction. In fact, the protocol spoken e.g. channel switching, VoD interaction. In fact, the protocol
between peers and super nodes is more like what we normally called spoken between peers and super nodes is more like what we would
"Tracker Protocol". It enables super nodes to check peer status, normally called "Tracker Protocol". It enables super nodes to check
maintain peer lists for several, if not all, channels. It provides peer status and maintain peer lists for several, if not all, channels.
peer list/content servers to peers. Thus, in the rest of this
section, when we mention Tracker Protocol, we mean the one used It provides peer list/content servers to peers. Thus, in the rest of
this section, when we mention Tracker Protocol, we mean the one used
between peers and super nodes. between peers and super nodes.
Peers will communicate with super nodes in some scenarios using Peers will communicate with super nodes in some scenarios using
Tracker Protocol. Tracker Protocol.
1. When a peer starts Joost software, after the installation and 1. When a peer starts Joost software, after the installation and
bootstrapping, the peer will communicate with one or several super bootstrapping, the peer will communicate with one or several super
nodes to get a list of available peers/content servers. nodes to get a list of available peers/content servers.
2. For on-demand video functions, super nodes periodically exchange 2. For on-demand video functions, super nodes periodically exchange
small UDP packets for peer management purpose. small UDP packets for peer management purpose.
3. When switching between channels, peers contact super nodes and 3. When switching between channels, peers contact super nodes to
the latter help the peers find available peers to fetch the requested find available peers for fetching the requested media data.
media data.
Peer Protocol: The following investigations are mainly motivated from Peer Protocol: The following investigations are mainly motivated from
[Joost- experiment ], in which a data-driven reverse-engineer [Joost- experiment], in which data-driven reverse-engineer
experiments are performed. We omitted the analysis process and experiments are performed. We omit the analysis process and
directly show the conclusion. Media data in Joost is split into directly show the conclusion. Media data in Joost is split into
chunks and then encrypted. Each chunk is packetized with about 5-10 chunks and then encrypted. Each chunk is packetized with about 5-10
seconds of video data. After receiving peer list from super nodes, a seconds of video data. After receiving peer list from super nodes, a
peer negotiates with some or, if necessary, all of the peers in the peer negotiates with some or, if necessary, all of the peers on the
list to find out what chunks they have. Then the peer makes decision list to find out what chunks they have. Then the peer makes decision
about from which peers to get the chunks. No peer capability about from which peers to get the chunks. No peer capability
information is exchanged in the Peer Protocol. information is exchanged in the Peer Protocol.
+---------------+ +-------------------+ +---------------+ +-------------------+
| Version Server| | Tracker Server | | Version Server| | Tracker Server |
+---------------+ +-------------------+ +---------------+ +-------------------+
\ | \ |
\ | \ |
\ | +---------------+ \ | +---------------+
skipping to change at page 8, line 27 skipping to change at page 8, line 27
| |
| |
| |
| |
+------------+ +---------+ +------------+ +---------+
| Super Node |-------| Peer2 | | Super Node |-------| Peer2 |
+------------+ +---------+ +------------+ +---------+
Figure 1, Architecture of Joost system Figure 1, Architecture of Joost system
The following sections describe Joost QoS related features, extracted The following sections describe Joost QoS related features,
mostly from [Joost- experiment], [JO2-Moreira] and [JO7-Joost Network extracted mostly from [Joost- experiment], [Moreira] and [Joost
Architecture]. Network Architecture].
For peer selection, Host Cache of a peer, which is refreshed For peer selection, Host Cache of a peer, which is refreshed
periodically, stores a list of Joost super nodes IP addresses and periodically, stores a list of Joost super nodes IP addresses and
ports. The selection strategy is influenced by the number of peers ports. The selection strategy is influenced by the number of peers
accessing the same content. Specifically, the number of candidate accessing the same content. Specifically, the number of candidate
peers made available is proportional to the number of active peers. peers made available is proportional to the number of active peers.
If there are a few of them, then Joost content server is made If there are only a few of them, then Joost content server is made
available to assist in the data delivery. Although there is no available to assist in the data delivery. Although there is no
explicit consideration for peer heterogeneities in peer selection, explicit consideration for peer heterogeneities in peer selection,
low capacity peers tend to partner with low capacity peer. Peers low capacity peers tend to partner with low capacity peer. Peers
under the same NAT also tend to serve each other preferentially [JO2- under the same NAT also tend to serve each other preferentially [
Moreira]. It may consider geographical locality but not have AS- Moreira]. It may consider geographical locality but may not have
level awareness or exploit topological locality and thus may have AS-level awareness or exploit topological locality and thus may
impact on the efficiency of video distribution. have impact on the efficiency of video distribution.
To maintain the overlay networks, super nodes probe clients, clients To maintain the overlay networks, super nodes probe clients, clients
probe clients and super nodes, and super nodes communicate with super probe clients and super nodes, and super nodes communicate with super
nodes and servers. To make up for inadequate bandwidth and to be nodes and servers. To make up for inadequate bandwidth and to be
scalable, Joost forms groups of Joost Server Islands, each island scalable, Joost forms groups of Joost Server Islands, each island
consisting of one streaming control server controlling ten streaming consisting of one streaming control server controlling up to ten
servers. Moreover, STUN protocol enables a client to discover streaming servers. Moreover, STUN protocol enables a client to
whether it is behind a NAT or firewall and the type of the NAT or discover whether it is behind a NAT or firewall and the type of the
firewall. NAT or firewall.
For data delivery, audio and video traffic are streamed separately to For data delivery, Joost streams audio and video traffic separately to
allow for multi-lingual programming. Content comes mostly from peers allow for multi-lingual programming. Content comes mostly from peers
and occasionally from content server for !olong-tail!+/- content. As and occasionally from content server for "long-tail" content. As
peers are assumed to contribute in a best-effort manner, peers are assumed to contribute in a best-effort manner,
infrastructures are needed to make up for insufficient bandwidth, infrastructures are needed to make up for insufficient bandwidth,
including in the asymmetric scenario. However, super nodes are not including in the asymmetric scenario. However, super nodes are not
part of the bandwidth supplying infrastructures as they only relay part of the bandwidth supplying infrastructures as they only relay
control traffic but not data traffic to clients. To support the P2P control traffic but not data traffic to clients. To support the P2P
media distribution services, Joost uses an agent based peer-to-peer media distribution services, Joost uses an agent based peer-to-peer
system called Anthill. Joost also employs Local Video Cache for system called Anthill. Joost also employs Local Video Cache for
later viewing and to avoid reloading but will still require later viewing and to avoid reloading, but it will still require
authorization from Joost server when accessing the video file at a authorization from Joost server when accessing the locally cached video
later time. file at a later time.
Joost provides large buffering and thus causes longer start-up delay Joost provides large buffering and thus causes longer start-up delay
for VoD traffic than for live media streaming traffic. It affords for VoD traffic than for live media streaming traffic. It affords
more FEC for VoD traffic but gives higher priority in delivery to more FEC for VoD traffic but gives higher priority in delivery to
live media streaming traffic. live media streaming traffic.
For Joost, load-balancing and fault-tolerance is shifted directly For Joost, load-balancing and fault-tolerance is shifted directly
into the client and all is done natively in the p2p code. into the client and all is done natively in the p2p code.
To enhance user viewing experience, Joost provides chat capability To enhance user viewing experience, Joost provides chat capability
skipping to change at page 10, line 4 skipping to change at page 10, line 4
Octoshape, thus no Tracker Protocol is required. Peers obtain live Octoshape, thus no Tracker Protocol is required. Peers obtain live
streaming from content servers and peers over Octoshape Protocol. streaming from content servers and peers over Octoshape Protocol.
Several data streams are constructed from live stream. No data Several data streams are constructed from live stream. No data
streams are identical and any number K of data streams can streams are identical and any number K of data streams can
reconstruct the original live stream. The number K is based on the reconstruct the original live stream. The number K is based on the
original media playback rate and the playback rate of each data original media playback rate and the playback rate of each data
stream. For example, a 400Kbit/s media is split into four 100Kbit/s stream. For example, a 400Kbit/s media is split into four 100Kbit/s
data streams, and then k = 4. Data streams are constructed in peers, data streams, and then k = 4. Data streams are constructed in peers,
instead of Broadcast server, which release server from large burden. instead of Broadcast server, which release server from large burden.
The number of data streams constructed in a particular peer equals The number of data streams constructed in a particular peer equals
the number of peers downloading data from the particular peer, which the number of peers downloading data from that particular peer, which
is constrained by the upload capacity of the particular peer. To get is constrained by the upload capacity of the particular peer. To get
the best performance, the upload capacity of a peer should be larger the best performance, the upload capacity of a peer should be larger
than the playback rate of the live stream. If not, an artificial than the playback rate of the live stream. If not, an artificial
peer may be added to deliver extra bandwidth. peer may be added to deliver extra bandwidth.
Each single peer has an address book of other peers who is watching Each single peer has an address book of other peers who is watching
the same channel. A Standby list is set up based on the address the same channel. A Standby list is set up based on the address
book. The peer periodically probes/asks the peers in the standby book. The peer periodically probes/asks the peers on the standby
list to be sure that they are ready to take over if one of the list to be sure that they are ready to take over if one of the
current senders stops or gets congested. [Octoshape] current senders stops or gets congested. [Octoshape]
Peer Protocol: The live stream is firstly sent to a few peers in the Peer Protocol: The live stream is initially sent to a few peers in
network and then spread to the rest of the network. When a peer the network and then spread to the rest of the network. When a peer
joins a channel, it notifies all the other peers about its presence joins a channel, it notifies all the other peers about its presence
using Peer Protocol, which will drive the others to add it into their using Peer Protocol, which will drive the others to add it into their
address books. Although [Octoshape] declares that each peer records address books. Although [Octoshape] declares that each peer records
all the peers joining the channel, we suspect that not all the peers all the peers joining the channel, we suspect that not all the peers
are recorded, considering the notification traffic will be large and are recorded, considering the notification traffic will be large and
peers will be busy with recording when a popular program starts in a peers will be busy with recording when a popular program starts in a
channel and lots of peers switch to this channel. Maybe some channel and lots of peers switch to this channel. Maybe some
geographic or topological neighbors are notified and the peer gets geographic or topological neighbors are notified and the peer gets
its address book from these nearby neighbors. its address book from these nearby neighbors.
The peer sends requests to some selected peers for the live stream The peer sends requests to some selected peers for the live stream
and the receivers answers OK or not according to their upload and the receivers answers OK or not according to their upload
capacity. The peer continues sending requests to peers until it capacity. The peer continues sending requests to peers until it
finds enough peers to provide the needed data streams to redisplay finds enough peers to provide the needed data streams to redisplay
the original live stream. The details of Octoshape are (not?) the original live stream. The details of Octoshape are not publicly
disclosed yet, we hope someone else can provide much specific disclosed, we hope someone else can provide more specific
information. information.
+------------+ +--------+ +------------+ +--------+
| Peer 1 |---| Peer 2 | | Peer 1 |---| Peer 2 |
+------------+ +--------+ +------------+ +--------+
| \ / | | \ / |
| \ / | | \ / |
| \ | | \ |
| / \ | | / \ |
| / \ | | / \ |
skipping to change at page 11, line 28 skipping to change at page 11, line 28
***************************************** *****************************************
| |
| |
+---------------+ +---------------+
| Content Server| | Content Server|
+---------------+ +---------------+
Figure 2, Architecture of Octoshape system Figure 2, Architecture of Octoshape system
The following sections describe Octoshape QoS related features, The following sections describe Octoshape QoS related features,
extracted mostly from [OctoshapeWeb], [OC2-Alstrup] and [OC3- extracted mostly from [OctoshapeWeb], [Alstrup1] and [
Alstrup]. As it is a closed system, the details of how the features Alstrup2]. As it is a closed system, the details of how the features
are implemented are not available. are implemented are not available.
To spread the burden of data distribution across several peers and To spread the burden of data distribution across several peers and
thus limiting the impact of peer loss, Octoshape splits a live stream thus limiting the impact of peer loss, Octoshape splits a live stream
into a number of smaller equal-sized sub-streams. For example, a into a number of smaller equal-sized sub-streams. For example, a
400kbit/s live stream is split and coded into 12 distinct 100kbit/s 400kbit/s live stream is split and coded into 12 distinct 100kbit/s
sub-streams. Only a subset of these sub-streams needs to reach a sub-streams. Only a subset of these sub-streams needs to reach a
user for it to reconstruct the !(R)original!_ live stream. The user for it to reconstruct the "original" live stream. The
number of distinct sub-streams could be as many as the number of number of distinct sub-streams could be as many as the number of
active peers. active peers.
Therefore, even if the upload capacity of a peer is smaller than its Therefore, even if the upload capacity of a peer is smaller than its
download capacity, it would now be easier to contribute a sub-stream download capacity, it would now be easier to contribute a sub-stream
than a whole live stream. An Octoshape peer can then receive from than a whole live stream. An Octoshape peer can then receive from
each neighboring peer at least a distinct sub-stream. To make up for each neighboring peer at least a distinct sub-stream. To make up for
the bandwidth asymmetry, artificial end users are used to deliver the bandwidth asymmetry, artificial end users are used to deliver
additional bandwidth. Multi OctoServers are also available to additional bandwidth. Multi OctoServers are also available to
guarantee no single point of failure [OC3-Alstrup]. guarantee no single point of failure [Alstrup2].
Octoshape keeps peer!_s availability information in an address book. Octoshape keeps peer availability information in an address book.
Each peer keeps a periodically updated stand-by list and passes it Each peer keeps a periodically updated stand-by list and passes it
along with its transmitted sub-stream. With constant monitoring of along with its transmitted sub-stream. With constant monitoring of
the quality and consistency of each content source, the peer can the quality and consistency of each content source, the peer can
switch partners in case of bottleneck and congestion to a better switch partners in case of bottleneck and congestion to a better
source. source.
Octoshape provides operator to control who should and should not Octoshape provides operator to control who should and should not
receive certain video signal due to copyright restriction, to control receive certain video signal due to copyright restriction, to control
access based in part on IP numbers, and to obtain real time access based in part on IP numbers, and to obtain real time
statistics during any live events. statistics during any live events.
To optimize bandwidth utilization, Octoshape leverages computers To optimize bandwidth utilization, Octoshape leverages computers
within a network to minimize external bandwidth usage and to select within a network to minimize external bandwidth usage and to select
the most reliable and !oclosest!+/- source to each viewer. It also the most reliable and "closest" source to each viewer. It also
chooses the best matching available codecs and players and scales bit chooses the best matching available codecs and players and scales bit
rate up and down according to available internet connection. rate up and down according to available internet connection.
Octoshape [OctoshapeWeb] claims to have patented resiliency and Octoshape [OctoshapeWeb] claims to have patented resiliency and
throughput technologies to deliver quality streams to the mobile and throughput technologies to deliver quality streams to the mobile and
wireless edge networks. This throughput optimization technology also wireless edge networks. This throughput optimization technology also
cleans up latent and lossy network connections between the encoder cleans up latent and lossy network connections between the encoder
and the distribution point, providing a stable, high quality, stream and the distribution point, providing a stable, high quality, stream
for distribution. Octoshape also claims to be able to deliver true for distribution. Octoshape also claims to be able to deliver true
HD, 1280x720 30fps (720p) video over the Internet and to have HD, 1280x720 30fps (720p) video over the Internet and to have
skipping to change at page 12, line 42 skipping to change at page 12, line 42
It has two major communication protocols. One is Registration and It has two major communication protocols. One is Registration and
peer discovery protocol, i.e. Tracker Protocol, and the other is P2P peer discovery protocol, i.e. Tracker Protocol, and the other is P2P
chunk distribution protocol, i.e. Peer Protocol. Figure 3 shows the chunk distribution protocol, i.e. Peer Protocol. Figure 3 shows the
architecture of PPLive. architecture of PPLive.
Tracker Protocol: First, a peer gets the channel list from the Tracker Protocol: First, a peer gets the channel list from the
Channel server, in a way similar to that of Joost. Then the peer Channel server, in a way similar to that of Joost. Then the peer
chooses a channel and asks the Tracker server for the peerlist of chooses a channel and asks the Tracker server for the peerlist of
this channel. this channel.
Peer Protocol: The peer contacts the peers in its peerlist to get Peer Protocol: The peer contacts the peers on its peerlist to get
additional peerlists, which are aggregated with its existing list. additional peerlists, which are aggregated with its existing list.
Through this list, peers can maintain a mesh for peer management and Through this list, peers maintain a mesh for peer management and
data delivery. data delivery.
For the video-on-demand (VoD) operation, because different peers For the video-on-demand (VoD) operation, because different peers
watch different parts of the channel, a peer buffers up to a few watch different parts of the channel, a peer buffers up to a few
minutes worth of chunks within a sliding window to share with each minutes worth of chunks within a sliding window to share with each
others. Some of these chunks may be chunks that have been recently others. Some of these chunks may be chunks that have been recently
played; the remaining chunks are chunks scheduled to be played in the played; the remaining chunks are chunks scheduled to be played in the
next few minutes. Peers upload chunks to each other. To this end, next few minutes. Peers upload chunks to each other. To this end,
peers send to each other "buffer-map" messages; a buffer-map message peers send to each other "buffer-map" messages; a buffer-map message
indicates which chunks a peer currently has buffered and can share. indicates which chunks a peer currently has buffered and can share.
The buffer-map message includes the offset (the ID of the first The buffer-map message includes the offset (the ID of the first
chunk), the length of the buffer map, and a string of zeroes and ones chunk), the length of the buffer map, and a string of zeroes and ones
indicating which chunks are available (starting with the chunk indicating which chunks are available (starting with the chunk
designated by the offset). PPlive transfer Data over UDP. designated by the offset). PPlive transfer Data over UDP.
Video Download Policy of PPLive Video Download Policy of PPLive
1 Top ten peers contribute to a major part of the download 1 Top ten peers contribute most of the downloaded
traffic. Meanwhile, the top peer session is quite short compared traffic. Meanwhile, the top peer session is quite short compared
with the video session duration. This would suggest that PPLive with the video session duration. This would suggest that a PPLive
gets video from only a few peers at any given time, and switches peer gets video from only a few peers at any given time, and
periodically from one peer to another; switches periodically from one peer to another;
2 PPLive can send multiple chunk requests for different chunks to 2 PPLive can send multiple chunk requests for different chunks to
one peer at one time; one peer at one time;
PPLive maintains a constant peer list with relatively small number of PPLive maintains a constant peer list with relatively small number of
peers. [P2PIPTV-measuring] peers. [P2PIPTV-measuring]
+------------+ +--------+ +------------+ +--------+
| Peer 2 |----| Peer 3 | | Peer 2 |----| Peer 3 |
+------------+ +--------+ +------------+ +--------+
| | | |
skipping to change at page 13, line 43 skipping to change at page 13, line 43
| |
| |
| |
+---------------+ +---------------+
| Tracker Server| | Tracker Server|
+---------------+ +---------------+
Figure 3, Architecture of PPlive system Figure 3, Architecture of PPlive system
The following sections describe PPLive QoS related features, The following sections describe PPLive QoS related features,
extracted mostly from [PL3-Hei], [PL5-Vu], [PL6-Liu], and [PL7-Liu]. extracted mostly from [Hei], [Vu], [Horvath], and [Liu].
After obtaining an initial peer list from the member server, a peer After obtaining an initial peer list from the member server, a peer
periodically updates its peer list by querying both member server and periodically updates its peer list by querying both member server and
partner peers. New peers are aggressively contacted at a fixed rate. partner peers. New peers are aggressively contacted at a fixed rate.
In selecting peers as partners, a peer considers their upload- In selecting peers as partners, a peer considers their upload-
bandwidth and in part, their location information [PL6-Horvath] in bandwidth and in part, their location information [Horvath] by
selecting on a FCFS basis those that have responded [PL7-Liu]. selecting on a FCFS basis those that have responded [Liu].
For data distribution, PPLive, a data-driven or mesh-pull scheme For data distribution, PPLive, using a data-driven or mesh-pull scheme
[PL3-Hei], divides the media content into small portions called [Hei], divides the media content into small portions called
chunks uses and TCP for video streaming. Neighbor peers use a chunks and uses TCP for video streaming. Neighbor peers use a
gossip-like protocol to exchange their buffer map that indicates gossip-like protocol to exchange their buffer maps that indicate
chunks available for sharing. Peers obtain one or more their missing chunks available for sharing. Peers obtain one or more of their
chunks from one or more peers having them. Available chunks may also missing chunks from one or more peers having them. Available chunks
be downloaded from the original channel server. may also be downloaded from the original channel server.
PPLive uses a double buffering mechanism consisting of TV Engine and PPLive uses a double buffering mechanism consisting of the TV Engine
Media Player for its stream reassembly and display [PL3-Hei]. The TV and the Media Player for its stream reassembly and display [Hei]. The
Engine is responsible for downloading video chunks from the PPLive TV Engine is responsible for downloading video chunks from the PPLive
network and streaming the downloaded video to the Media Player, which network and streaming the downloaded video to the Media Player, which
in turns displays the content to the user, after each buffer is in turns displays the content to the user, after each buffer is
filled up to its respective predetermined threshold. filled up to its respective predetermined threshold.
PPLive is observed to have the download scheduling policy of giving PPLive is observed to have the download scheduling policy of giving
higher priority to rare chunks and to chunks closer to play out higher priority to rare chunks and to chunks closer to play out
deadline and to be using a sliding window mechanism to regulate the deadline and to be using a sliding window mechanism to regulate the
buffering of chunks. buffering of chunks.
To utilize available peer resources, peers in one subscribed overlay To utilize available peer resources, peers in one subscribed overlay
may also be harnessed to support peers in other subscribed overlays may also be harnessed to support peers in other subscribed overlays
[PL5-Vu]. [Vu].
3.1.4. Zattoo 3.1.4. Zattoo
Zattoo is P2P live streaming system which serves over 3 million Zattoo is P2P live streaming system which serves over 3 million
registered users over European countries [Zattoo].The system delivers registered users over European countries [Zattoo].The system delivers
live streaming using a receiver-based, peer-division multiplexing live streaming using a receiver-based, peer-division multiplexing
scheme. Zattoo reliably streams media among peers using the mesh scheme. Zattoo reliably streams media among peers using the mesh
structure. structure.
Figure 4 depicts a typical procedure of single TV channel carried Figure 4 depicts the basic architecture of a Zatto system. First,
over Zattoo network. First, Zattoo system broadcasts live TV, the Zattoo system broadcasts live TV, captured from satellites, onto
captured from satellites, onto the Internet. Each TV channel is the Internet. Each TV channel is delivered through a separate P2P
delivered through a separate P2P network. network.
------------------------------- -------------------------------
| ------------------ | -------- | ------------------ | --------
| | Broadcast | |---------|Peer1 |----------- | | Broadcast | |---------|Peer1 |-----------
| | Servers | | -------- | | | Servers | | -------- |
| Administrative Servers | ------------- | Administrative Servers | -------------
| ------------------------ | | Super Node| | ------------------------ | | Super Node|
| | Authentication Server | | ------------- | | Authentication Server | | -------------
| | Rendezvous Server | | | | | Rendezvous Server | | |
| | Feedback Server | | -------- | | | Feedback Server | | -------- |
| | Other Servers | |---------|Peer2 |----------| | | Other Servers | |---------|Peer2 |----------|
| ------------------------| | -------- | ------------------------| | --------
------------------------------| ------------------------------|
Figure 4, Basic architecture of Zattoo system Figure 4, Basic architecture of Zattoo system
Tracker(Rendezvous Server) Protocol: In order to receive the signal Tracker (Rendezvous Server) Protocol: In order to receive the signal
the requested channel, registered users are required to be of the requested channel, all registered users are required to be
authenticated through Zattoo Authentication Server. Upon authenticated through the Zattoo Authentication Server. Upon
authentication, users obtain a ticket with specific lifetime. Then, authentication, each user obtains a ticket with a specific lifetime.
users contact Rendezvous Server with the ticket and identify of Then, the user then contacts Rendezvous Server with the ticket and
interested TV channel. In return, the Rendezvous Server sends back a identifies the TV channel of interested. In return, the Rendezvous
list joined peers carrying the channel. Server sends back a list of active peers carrying the channel.
Peer Protocol: Similar to aforementioned procedures in Joost, PPLive, Peer Protocol: Similar to aforementioned procedures in Joost and
a new Zattoo peer requests to join an existing peer among the peer PPLive, a newly joined Zattoo peer requests to partner with peers from
list. Upon the availability of bandwidth, requested peer decides how among the obtained peer list. Based on the availability of bandwidth,
to multiplex a stream onto its set of neighboring peers. When a requested peer decides how to multiplex a stream onto its set of
packets arrive at the peer, sub-streams are stored for reassembly neighboring peers. When the requesting peer receives packets, it stores
constructing the full stream. them to form sub-streams for reassembling the full stream.
Note Zattoo relies on Bandwidth Estimation Server to initially Note Zattoo relies on the Bandwidth Estimation Server to initially
estimate the amount of available uplink bandwidth at a peer. Once a estimate the amount of available uplink bandwidth at a peer. Once a
peer starts to forward substream to other peers, it receives QoS peer starts to forward substreams to other peers, it receives QoS
feedback from other receivers if the quality of sub-stream drops feedback from the receiver of the substreams for any received sub-stream
below a threshold. quality that drops below a threshold.
The following sections describe Zattoo QoS related features, The following sections describe Zattoo QoS related features,
extracted mostly from [ZT1-Chang]. extracted mostly from [Chang].
For reliable data delivery, each live stream is partitioned into For reliable data delivery, each live stream is partitioned into
video segments. Each video segment is coded for forward error video segments. Each video segment is coded for forward error
correction with Reed-Solomon error correcting code into n sub-stream correction with Reed-Solomon error correcting code into n sub-stream
packets such that having obtained k correct packets of a segment is packets such that having obtained k correct packets of a segment is
sufficient to reconstruct the remaining n-k packets of the same video sufficient to reconstruct the remaining n-k packets of the same video
segment. To receive a video segment, each peer then specifies the segment. To receive a video segment, each peer then specifies the
sub-stream(s) of the video segment it would like to receive from the sub-stream(s) of the video segment it would like to receive from the
neighboring peers. neighboring peers.
Zattoo uses Peer-Division Multiplexing (PDM) scheme for its data Zattoo uses the Peer-Division Multiplexing (PDM) scheme for its data
delivery topology setup. In this scheme, each new peer independently delivery topology setup. In this scheme, each new peer independently
executes the Search and Join phases. In the Search Phase, a peer executes the Search and Join phases. In the Search Phase, a peer
queries the members of the peer list for sub-streams availability; in queries the members of the peer list for sub-streams availability; in
response, receives additional prospective peers, sub-streams response, it receives additional prospective peers, sub-streams
availability, quality indications, and sub-stream sequence numbers; availability, quality indications, and sub-stream sequence numbers;
and then selects, among the responses, partnering peers or quits and it then selects, among the responses, partnering peers or quits
after failing two search attempts. after failing two search attempts.
In the Join Phase, a joining peer, having selected the candidate In the Join Phase, a joining peer, having selected the candidate
peers, requests to partner with some of them, spreading the load peers, requests to partner with some of them, spreading the load
among them and preferring topologically close-by peers, if these among them and preferring topologically close-by peers, if these
peers have less capacity or carry lower quality sub-streams. Barring peers have less capacity or carry lower quality sub-streams. Barring
departure or performance degradation of neighboring peers, the departure or performance degradation of neighboring peers, the
established connections stay and the specified sub-stream packet of established connections persist and the specified sub-stream packet
every segment continues to be forwarded without further per-packet of every segment continues to be forwarded without further per-packet
handshaking between peers. handshaking between peers.
To manage stream efficiently for incoming and outgoing destinations, To manage stream efficiently for incoming and outgoing destinations,
each peer has a packet buffer, called IOB (Input-Output Buffer). The each peer has a packet buffer, called IOB (Input-Output Buffer). The
IOB is referenced by an input pointer, a repair pointer, and one or IOB is referenced by an input pointer, a repair pointer and one or
more output pointers, one for each forwarding destination such as more output pointers, one for each forwarding destination such as
player, file, and other peer. The input pointer points to the slot player, file, and other peer. The input pointer points to the slot
in the IOB where the next incoming packet with sequence number higher in the IOB where the next incoming packet with sequence number higher
than the highest sequence number received so far will be stored, and than the highest sequence number received so far will be stored, and
the repair pointer always points to one slot beyond the last packet the repair pointer always points to one slot beyond the last packet
received in order and is used to regulate packet retransmission and received in order and is used to regulate packet retransmission and
adaptive PDM (to be described later). A packet map and forwarding adaptive PDM (to be described later). A packet map and forwarding
discipline is associated with each output pointer to accommodate the discipline is associated with each output pointer to accommodate the
different forwarding rates and regimes required by the destinations. different forwarding rates and regimes required by the destinations.
Note that retransmission requests are sent to random peers and not to Note that retransmission requests are sent to random peers and not to
partnering peers and they are honoured only if the requested packets partnering peers. Furthermore, they are honoured only if the requested
are still in IOB and there is sufficient left-over capacity to packets are still in IOB and there is sufficient left-over capacity to
transmit all the requested packets. To avoid buffer overrun, a set transmit all the requested packets. To avoid buffer overrun, a set
of two buffers is used in the IOB instead of a circular buffer. of two buffers is used in the IOB instead of a circular buffer.
Zattoo uses Adaptive Peer-Division Multiplexing scheme to handle Zattoo uses Adaptive Peer-Division Multiplexing (PDM) scheme to handle
longer term bandwidth fluctuations. In this scheme, each peer longer term bandwidth fluctuations. In this scheme, each peer
determines how many sub-streams to transmit and when to switch determines how many sub-streams to transmit and when to switch
partners. Specifically, each peer continually estimates the amount partners. Specifically, each peer continually estimates the amount
of available uplink bandwidth based initially on probe packets to the of available uplink bandwidth based initially on probe packets to the
Zattoo Bandwidth Estimation Server and later, based on peer QoS Zattoo Bandwidth Estimation Server and later, based on peer QoS
feedbacks, using different algorithms depending on the underlying feedbacks, using different algorithms depending on the underlying
transport protocol. A peer increases its estimated available uplink transport protocol. A peer increases its estimated available uplink
bandwidth, if the current estimate is below some threshold and if bandwidth, if the current estimate is below some threshold and if
there has been no bad quality feedback from neighboring peers for a there has been no bad quality feedback from neighboring peers for a
period of time, according to some algorithm similar to how TCP period of time, according to some algorithm similar to how TCP
maintains its congestion window size. Each peer then admits maintains its congestion window size. Each peer then admits
neighbors based on the currently estimated available uplink neighbors based on the currently estimated available uplink
bandwidth. In case a new estimate indicates insufficient bandwidth bandwidth. In case a new estimate indicates insufficient bandwidth
to support the existing number of peer connections, one connection at to support the existing number of peer connections, one connection at
a time, preferably starting with the one requiring the least a time, preferably starting with the one requiring the least
bandwidth, is closed. On the other hand, if loss rate of packets bandwidth, is closed. On the other hand, if loss rate of packets
from a peer!_s neighbor reaches a certain threshold, the peer will from a peer's neighbor reaches a certain threshold, the peer will
attempt to shift the degraded neighboring peer load to other existing attempt to shift the degraded neighboring peer load to other existing
peers, while looking for replacement peer. When a replacement is peers, while looking for a replacement peer. When one is
found, the load is shifted to it and the degraded neighbor is found, the load is shifted to it and the degraded neighbor is
dropped. As expected if a peer!_s neighbor is lost due to departure, dropped. As expected if a peer's neighbor is lost due to departure,
the peer initiates the process to replace the lost peer. To optimize the peer initiates the process to replace the lost peer. To optimize
the PDM configuration, a peer may occasionally initiate switching the PDM configuration, a peer may occasionally initiate switching
existing partnering peers to topologically closer peers. existing partnering peers to topologically closer peers.
3.1.5. PPStream 3.1.5. PPStream
The system architecture and working flows of PPStream is similar to The system architecture and working flows of PPStream is similar to
PPLive. PPStream transfers data using mostly TCP, only occasionally PPLive. PPStream transfers data using mostly TCP, only occasionally
UDP. UDP.
skipping to change at page 17, line 37 skipping to change at page 17, line 37
many peers simultaneously, and its peers have long session many peers simultaneously, and its peers have long session
duration; duration;
2 PPStream does not send multiple chunk requests for different 2 PPStream does not send multiple chunk requests for different
chunks to one peer at one time; chunks to one peer at one time;
PPStream maintains a constant peer list with relatively large number PPStream maintains a constant peer list with relatively large number
of peers. [P2PIPTV-measuring] of peers. [P2PIPTV-measuring]
The following sections describe PPStream QoS related features, The following sections describe PPStream QoS related features,
extracted mostly from [PS3-Li], [PS4-Jia] and [PS5-Wei]. extracted mostly from [Li], [Jia] and [Wei].
PPStream is mainly mesh-based but to some extent it is layered in its PPStream is mainly mesh-based but to some extent has a layered data
data distribution topology. It uses geographic clustering to some distribution topology. It uses geographic clustering to some
extent based on geographic longitude and latitude of the IP addresses extent based on geographic longitude and latitude of the IP addresses
[PS4-Jia]. [Jia].
To ensure data availability, some form of chunk retransmission To ensure data availability, PPStream uses some form of chunk
request mechanism is used and the buffer map is shared at high rate, retransmission request mechanism and shares buffer map at high rate,
although concurrent requests for the same data chunk is rare. Each although it rarely requests concurrently for the same data chunk. Each
data chunk, identified by the play time offset encoded by the program data chunk, identified by the play time offset encoded by the program
source, is divided into 128 sub-chunks of 8KB size each. The chunk source, is divided into 128 sub-chunks of 8KB size each. The chunk
id is used to ensure sequential ordering of received data chunk. id is used to ensure sequential ordering of received data chunk.
The buffer map consists of one or more 128-bit flags denoting the The buffer map consists of one or more 128-bit flags denoting the
availability of sub-chunks and having a corresponding time offset. availability of sub-chunks and having a corresponding time offset.
Usually a buffer map contains only one data chunk at a time and is Usually a buffer map contains only one data chunk at a time and is
thus smaller than that of PPLive. It also contains sending peer!_s thus smaller than that of PPLive. It also contains sending peer's
playback status to the other peers because as soon as a data chunk is playback status to the other peers because as soon as a data chunk is
played back, the chunk is deleted or replaced by the next data chunk played back, the chunk is deleted or replaced by the next data chunk
[PS5-Wei]. [Wei].
At the initiating stage, a peer can use up to 4 data chunks and on a At the initiating stage, a peer can use up to 4 data chunks and on a
stabilized stage, a peer uses usually one data chunk. However, in stabilized stage, a peer uses usually one data chunk. However, in
transient stage, a peer uses variable number of chunks. Although, transient stage, a peer uses variable number of chunks. Although,
sub-chunks within each data chunks are fetched nearly in random sub-chunks within each data chunks are fetched nearly in random
without using rarest or greedy policy, the same fetching pattern for without using rarest or greedy policy, the same fetching pattern for
one data chunk seems to repeat in the following data chunks [PS3-Li]. one data chunk seems to repeat in the following data chunks [Li].
Moreover, high bandwidth PPStream peers tend to receive chunks Moreover, high bandwidth PPStream peers tend to receive chunks
earlier and contributes more than lower bandwidth peers. earlier and thus to contributes more than lower bandwidth peers.
3.1.6. SopCast 3.1.6. SopCast
The system architecture and working flows of SopCast is similar to The system architecture and working flows of SopCast is similar to
PPLive. SOPCast transfer data mainly using UDP, occasionally TCP; PPLive. SOPCast transfers data mainly using UDP, occasionally TCP;
Top ten peers contribute to about half of the total download traffic. Top ten peers contribute to about half of the total download traffic.
SOPCast's download policy is similar to PPLive's policy in that it SOPCast's download policy is similar to PPLive's policy in that it
switches periodically between provider peers. However, SOPCast seems switches periodically between provider peers. However, SOPCast seems
to always need more than one peer to get the video, while in PPLive a to always need more than one peer to get the video, while in PPLive a
single peer could be the only video provider; single peer could be the only video provider;
SOPCast's peer list can be as large as PPStream's peer list. But SOPCast's peer list can be as large as PPStream's peer list. But
SOPCast's peer list varies over time. [P2PIPTV-measuring] SOPCast's peer list varies over time. [P2PIPTV-measuring]
The following sections describe SopCast QoS related features, The following sections describe SopCast QoS related features,
extracted mostly from [SC1-Ali], [SC2-Ciullo], [SC4-Fallica], [SC5- extracted mostly from [Ali], [Ciullo], [Fallica], [Sentinelli],
Sentinelli], [SC6-Silverston], and [SC7-Tang]. [SC6-Silverston], and [SC7-Tang].
SopCast allows for software update through (HTTP) a centralized web SopCast allows for software update through (HTTP) a centralized web
server and makes available channel list through (HTTP) another server and makes available channel list through (HTTP) another
centralized server. centralized server.
SopCast traffic is encoded and SopCast TV content is divided into SopCast traffic is encoded and SopCast TV content is divided into
video chunks or blocks with equal sizes of 10KB [SC7-Tang]. Sixty video chunks or blocks with equal sizes of 10KB [Tang]. Sixty
percent of its traffic is signaling packets and 40% is actual video percent of its traffic is signaling packets and 40% is actual video
data packets [SC4-Fallica]. SopCast produces more signaling traffic data packets [Fallica]. SopCast produces more signaling traffic
compared to PPLive, PPStream, and TVAnts, whereas PPLive produces the compared to PPLive, PPStream, and TVAnts, whereas PPLive produces the
least [SC6-Silverston]. Its traffic is also noted to have long-range least [Silverston]. Its traffic is also noted to have long-range
dependency [SC6-Silverston], indicating that mitigating it with QoS dependency [Silverston], indicating that mitigating it with QoS
mechanisms may be difficult. [SC1-Ali] reported that SopCast mechanisms may be difficult. [Ali] reported that SopCast
communication mechanism starts with UDP for the exchange of control communication mechanism starts with UDP for the exchange of control
messages among its peers using a gossip-like protocol and then moves messages among its peers using a gossip-like protocol and then moves
to TCP for the transfer of video segments. This use of TCP for data to TCP for the transfer of video segments. This use of TCP for data
transfer seems to contradict others findings [SC4-Fallica, SC6- transfer seems to contradict others findings [Fallica, Silverston].
Silverston].
To discover candidate peers, a peer requests peer list from Tracker, To discover candidate peers, a peer requests peer list from Tracker,
or from neighboring peer using a gossip-like protocol. To retrieve or from neighboring peer using a gossip-like protocol. To retrieve
content [SC4-Fallica], a new peer contacts peers selected randomly content [Fallica], a new peer contacts peers selected randomly
from the peer list it obtained from having queried the root servers from the peer list it obtained from having queried the root servers
(trackers). The process of contacting peers slows down after the (trackers). The process of contacting peers slows down after the
initial bootstrap phase [SC3-Horvath, SC2-Ciullo]. The number of initial bootstrap phase [Horvath, Ciullo]. The number of
peers a node typically connects to for download is about 2 to 5 [SC5- peers a node typically connects to for download is about 2 to 5 [SC5-
Sentinelli] and there is no observed preference for peers with Sentinelli] and there is no observed preference for peers with
shorter paths [SC2-Ciullo]. Partner peers periodically advertise shorter paths [Ciullo]. Partner peers periodically advertise
content availability and exchange sought content. In forming content availability and exchange sought content. In forming
multiple parent and children relationships, a peer does not exploit multiple parent and children relationships, a peer does not exploit
peer location information [SC3-Horvath]. In general, parents are peer location information [Horvath]. In general, parents are
chosen solely based on performance; however, lower capacity nodes chosen solely based on performance; however, lower capacity nodes
seem to be choosing parents that are closer to improve performance seem to be choosing parents that are closer to improve performance
and to compensate for its bandwidth constraints [SC1-Ali]. When and to compensate for its bandwidth constraints [Ali]. When
needed, a peer can download video streams directly from the Source needed, a peer can download video streams directly from the Source
Provide, a node that broadcasts the entire video [SC7-Tang]. In the Provide, a node that broadcasts the entire video [Tang]. In the
process of data exchange, there is no enforcement of tit-for-tat like process of data exchange, there is no enforcement of tit-for-tat like
mechanisms [SC2-Ciullo]. mechanisms [Ciullo].
Similar to PPLive, SopCast uses a double-buffering mechanism. The Similar to PPLive, SopCast uses a double-buffering mechanism. The
SopCast buffer downloads video chunks from the network, storing them, SopCast buffer downloads video chunks from the network, storing them,
and upon exceeding a predetermined number of stored chunks, launches and upon exceeding a predetermined number of stored chunks, launches
the Media player. The Media player buffer then downloads video the Media player. The Media player buffer then downloads video
content from the local web server listening port and upon receiving content from the local web server listening port and upon receiving
sufficient amount of content, starts video playback. sufficient amount of content, starts video playback.
3.1.7. TVants 3.1.7. TVants
The system architecture and working flows of TVants is similar to The system architecture and working flows of TVants is similar to
PPLive. TVAnts is more balanced between TCP and UDP in data PPLive. TVAnts is more balanced between TCP and UDP in data
transmission; transmission;
The system architecture and working flows of TVants is similar to
PPLive. TVAnts is more balanced between TCP and UDP in data
transmission;
TVAnts' peer list is also large and varies over time. [P2PIPTV- TVAnts' peer list is also large and varies over time. [P2PIPTV-
measuring] measuring]
We extract the common Main components and steps of PPLive, PPStream, We illustrate in Figure 5 the common Main components and steps of
SopCast and TVants, which is shown in Figure 5. PPLive, PPStream, SopCast and TVants.
+------------+ +------------+
| Tracker | | Tracker |
/+------------+ /+------------+
/ /
/ +------+ / +------+
1,2/ /|Peer 1| 1,2/ /|Peer 1|
/ / +------+ / / +------+
/ /3,4,6 / /3,4,6
+---------+/ +------+ +---------+/ +------+
skipping to change at page 20, line 26 skipping to change at page 20, line 26
|5 | \ |5 | \
|---| \ +------+ |---| \ +------+
3,4,6 \|Peer 3| 3,4,6 \|Peer 3|
+------+ +------+
Figure 5, Main components and steps of PPLive, PPStream, SopCast and Tvants Figure 5, Main components and steps of PPLive, PPStream, SopCast and Tvants
The main steps are: The main steps are:
(1) A new peer registers with tracker / distributed hash table (1) A new peer registers with tracker / distributed hash table
(DHT) to join the peer group which shares a same channel / media (DHT) to join the peer group sharing the same channel / media
content; content;
(2) Tracker / DHT returns an initial peer list to the new peer; (2) Tracker / DHT returns an initial peer list to the new peer;
(3) The new peer harvests peer lists by gossiping (i.e. exchange (3) The new peer harvests peer lists by gossiping (i.e. exchange
peer list) with the peers in the initial peer list to aggregate peer list) with the peers on the initial peer list to aggregate
more peers sharing the channel / media content; more peers sharing the channel / media content;
(4) The new peer randomly (or with some guide) selects some peers (4) The new peer randomly (or with some guide) selects some peers
from its peer list to connect and exchange peer information (e.g. from its peer list to connect and exchange peer information (e.g.
buffer map, peer status, etc) with connected peers to know where buffer map, peer status, etc) with connected peers to know where
to get what data; to get what data;
(5) The new peer decides what data should be requested in which (5) The new peer decides what data should be requested in which
order / priority using some scheduling algorithm and the peer order / priority using some scheduling algorithm and the peer
information obtained in Step (4); information obtained in Step (4);
(6) The new peer requests the data from some connected peers. (6) The new peer requests the data from some connected peers.
The following sections describe TVAnts QoS related features, The following sections describe TVAnts QoS related features,
extracted mostly from [TV1-Alessandria], [TV2-Ciullo], and [TV3- extracted mostly from [Alessandria], [Ciullo], and [Horvath].
Horvath].
TVAnts peer discovery mechanism is very greedy during the first part TVAnts peer discovery mechanism is very greedy during the first part
of a peer life and stabilizes afterwards [TV2-Ciullo]. of a peer life and stabilizes afterwards [Ciullo].
For data delivery, peers exhibit mild preference to exchange data For data delivery, peers exhibit mild preference to exchange data
among themselves in the same Autonomous System and also among peers among themselves in the same Autonomous System and also among peers
in the same subnet. TVAnts peer also exhibits some preference to in the same subnet. TVAnts peer also exhibits some preference to
download from closer peers. According to [TV3-Horvath], TVAnts peer download from closer peers. According to [Horvath], TVAnts peer
exploits location information and download mostly from high-bandwidth exploits location information and download mostly from high-bandwidth
peers. However, it does not seem to enforce any tit-for-tat peers. However, it does not seem to enforce any tit-for-tat
mechanisms in the data delivery. mechanisms in the data delivery.
TVAnts [TV1-Alessandria] seems to be sensitive to network impairments TVAnts [Alessandria] seems to be sensitive to network impairments
such as changes in network capacity, packet loss, and delay. For such as changes in network capacity, packet loss, and delay. For
capacity loss, a peer will always seek for more peers to download. capacity loss, a peer will always seek for more peers to download.
In the process of trying to avoid bad paths and selecting good peers In the process of trying to avoid bad paths and selecting good peers
to continue downloading data, aggressive and potentially harmful to continue downloading data, aggressive and potentially harmful
behavior for both application and the network results when bottleneck behavior for both application and the network results when bottleneck
is affecting all potential peers. is affecting all potential peers.
When limited access capacity is experienced, a peer reacts by When a peer experiences limited access capacity, it reacts by
increasing redundancy (with FEC or ARQ mechanism) as if reacting to increasing redundancy (with FEC or ARQ mechanism) as if reacting to
loss and thus causes higher download rate. To recover from packet loss and thus causes higher download rate. To recover from packet
losses, some kind of ARQ mechanism is also used. Although network losses, it uses some kind of ARQ mechanism. Although network
conditions do impact video stream distribution such as the network conditions do impact video stream distribution such as the network
delay impacting the start-up phase, they seem to have little impact delay impacting the start-up phase, they seem to have little impact
on the network topology discovery and maintenance process. on the network topology discovery and maintenance process.
3.2. Tree-based P2P streaming systems 3.2. Tree-based P2P streaming systems
3.2.1. PeerCast 3.2.1. PeerCast
PeerCast adopts a Tree structure. The architecture of PeerCast is PeerCast adopts a Tree structure. The architecture of PeerCast is
shown in Figure 6. shown in Figure 6.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
address. First of all, the peer sends a request to the server, and address. First of all, the peer sends a request to the server, and
the server answers OK or not according to its idle capability. If the server answers OK or not according to its idle capability. If
the broadcast server has enough idle capability, it will include the the broadcast server has enough idle capability, it will include the
peer in its child-list. Otherwise, the broadcast server will choose peer in its child-list. Otherwise, the broadcast server will choose
at most eight nodes of its children and answer the peer. The peer at most eight nodes of its children and answer the peer. The peer
records the nodes and contacts one of them, until it finds a node records the nodes and contacts one of them, until it finds a node
that can server it. that can server it.
In stead of requesting the channel by the peer, a Transfer node In stead of requesting the channel by the peer, a Transfer node
pushes live stream to its children, which can be a transfer node or a pushes live stream to its children, which can be a transfer node or a
receiver. A node in the tree will notify its status to its parent receiver. A node in the tree will notify its parent about its status
periodically, and the latter will update its child-list according to periodically, and the parent will update its child-list according to
the received notifications. the received notifications.
------------------------------ ------------------------------
| +---------+ | | +---------+ |
| | Tracker | | | | Tracker | |
| +---------+ | | +---------+ |
| | | | | |
| | | | | |
| +---------------------+ | | +---------------------+ |
| | Broadcast server | | | | Broadcast server | |
| +---------------------+ | | +---------------------+ |
skipping to change at page 22, line 35 skipping to change at page 22, line 35
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|Receiver1| |Receiver2| |Receiver3| |Receiver4| |Receiver1| |Receiver2| |Receiver3| |Receiver4|
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Figure 6, Architecture of PeerCast system Figure 6, Architecture of PeerCast system
The following sections describe PeerCast QoS related features, The following sections describe PeerCast QoS related features,
extracted mostly from [CVV1-Zhang], [CVV4-Chu], [CVV5-Chu], and extracted mostly from [Deshpande] and [Despande1].
[CVV6-Chu].
Each PeerCast node has a peering layer which is a layer between the Each PeerCast node has a peering layer that is between the
application layer and the transport layer. The peering layer of each application layer and the transport layer. The peering layer of each
node coordinates among similar nodes to establish and maintain a node coordinates among similar nodes to establish and maintain a
multicast tree. Moreover, the peering layer also supports simple, multicast tree. Moreover, the peering layer also supports a simple,
lightweight redirect primitive. This primitive allows a peer p to lightweight redirect primitive. This primitive allows a peer p to
direct another peer c which is either opening a data-transfer session direct another peer c which is either opening a data-transfer session
with p, or has a session already established with p to a target peer with p, or has a session already established with p to a target peer
t to try to establish a data-transfer session. Peer discovery starts t to try to establish a data-transfer session. Peer discovery starts
at the root (source) or some selected sub-tree root and goes at the root (source) or some selected sub-tree root and goes
recursively down the tree structure. When a peer leaves normally, it recursively down the tree structure. When a peer leaves normally, it
informs its parent who then releases the peer, and it also redirects informs its parent who then releases the peer, and it also redirects
all its immediate children to find new parents starting at some all its immediate children to find new parents starting at some
target t. target node.
The peering layer allows for different policies of topology The peering layer allows for different policies of topology
maintenance. In choosing a parent from among the children of a given maintenance. In choosing a parent from among the children of a given
peer, a child can be chosen randomly, one at a time in some fixed peer, a child can be chosen randomly, one at a time in some fixed
order, or based on least access latency with respect to the choosing order, or based on least access latency with respect to the choosing
peer. There are also many choices of peers to start and limit the peer. There are also many choices of peers to start and limit the
search. The different combinations are all the descendants of a search. The different combinations are all the descendants of a
leaving peer have to start searching from the root [root-All (RTA)]; leaving peer have to start searching from the root [root-All (RTA)];
only the children of a leaving peer have to start searching from the only the children of a leaving peer have to start searching from the
root [Root (RT)]; all the descendants of a leaving peer have to start root [Root (RT)]; all the descendants of a leaving peer have to start
skipping to change at page 23, line 40 skipping to change at page 23, line 40
[Knock-Down]. Newly arrived peer replaces the target peer and the [Knock-Down]. Newly arrived peer replaces the target peer and the
target peer becomes its child [Join-Flip]. Unstable peers are pushed target peer becomes its child [Join-Flip]. Unstable peers are pushed
down to the bottom of the tree [Leaf-Sink]. Existing child and down to the bottom of the tree [Leaf-Sink]. Existing child and
parent relationship is flipped [Maintain-Flip]. parent relationship is flipped [Maintain-Flip].
3.2.2. Conviva 3.2.2. Conviva
Conviva[TM][conviva] is a real-time media control platform for Conviva[TM][conviva] is a real-time media control platform for
Internet multimedia broadcasting. For its early prototype, End Internet multimedia broadcasting. For its early prototype, End
System Multicast (ESM) [ESM04] is the underlying networking System Multicast (ESM) [ESM04] is the underlying networking
technology on organizing and maintaining an overlay broadcasting technology for organizing and maintaining an overlay broadcasting
topology. Next we present the overview of ESM. ESM adopts a Tree topology. Next we present an overview of ESM. ESM adopts a Tree
structure. The architecture of ESM is shown in Figure 7. structure. The architecture of ESM is shown in Figure 7.
ESM has two versions of protocols: one for smaller scale conferencing ESM has two versions of protocols: one for the smaller scale conferencing
apps with multiple sources, and the other for larger scale apps with multiple sources, and the other for the larger scale
broadcasting apps with Single source. We focus on the latter version broadcasting apps with a single source. We focus on the latter version
in this survey. in this survey.
ESM maintains a single tree for its overlay topology. Its basic ESM maintains a single tree for its overlay topology. Its basic
functional components include two parts: a bootstrap protocol, a functional components include two parts: a bootstrap protocol, a
parent selection algorithm, and a light-weight probing protocol for parent selection algorithm, and a light-weight probing protocol for
tree topology construction and maintenance; a separate control tree topology construction and maintenance; a separate control
structure decoupled from tree, where a gossip-like algorithm is used structure decoupled from tree, where a gossip-like algorithm is used
for each member to know a small random subset of group members; for each member to know a small random subset of group members;
members also maintain pathes from source. members also maintain paths from source.
Upon joining, a node gets a subset of group membership from the Upon joining, a node gets a subset of group membership from the
source (the root node); it then finds parent using a parent selection source (the root node); it then finds parent using a parent selection
algorithm. The node uses light-weight probing heuristics to a subset algorithm. The node uses light-weight probing heuristics on a subset
of members it knows, and evaluates remote nodes and chooses a of members it knows, and evaluates remote nodes and chooses a
candidate parent. It also uses the parent selection algorithm to candidate parent. It also uses the parent selection algorithm to
deal with performance degradation due to node and network churns. deal with performance degradation due to node and network churns.
ESM Supports for NATs. It allows NATs to be parents of public hosts, ESM Supports for NATs. It allows NATs to be parents of public hosts,
and public hosts can be parents of all hosts including NATs as and public hosts can be parents of all hosts including NATs as
children. children.
------------------------------ ------------------------------
| +---------+ | | +---------+ |
| | Tracker | | | | Tracker | |
skipping to change at page 24, line 44 skipping to change at page 24, line 44
+---------+ +---------+ +---------+ +---------+
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| Peer3 | | Peer4 | | Peer5 | | Peer6 | | Peer3 | | Peer4 | | Peer5 | | Peer6 |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Figure 7, Architecture of ESM system Figure 7, Architecture of ESM system
The following sections describe ESM QoS related features, extracted The following sections describe only ESM QoS related features,
mostly from [CVV1-Zhang], [CVV4-Chu], [CVV5-Chu], and [CVV6-Chu], and extracted mostly from [ESM04], [Chu1], [Chu2], and [Chu3], as those
the details of Conviva are not publicly available. of the Conviva are not publicly available.
ESM constructs the multicast tree in a two-step process. It ESM constructs the multicast tree in a two-step process. It
constructs first a mesh of the participating peers; the mesh having constructs first a mesh of the participating peers; the mesh having
the following properties: the following properties:
o The shortest path delay between any pair of peers in the mesh is o The shortest path delay between any pair of peers in the mesh is
at most K times the unicast delay between them, where K is a small at most K times the unicast delay between them, where K is a small
constant. constant.
o Each peer has a limited number of neighbors in the mesh which does o Each peer has a limited number of neighbors in the mesh which does
not exceed a given (per-member) bound chosen to reflect the not exceed a given (per-member) bound chosen to reflect the
bandwidth of the peer!_s connection to the Internet. bandwidth of the peer's connection to the Internet.
It then constructs a (reverse) shortest path spanning trees of the It then constructs a (reverse) shortest path spanning trees of the
mesh with the root being the source. mesh with the root being the source.
Therefore a peer participates in two types of topology management: a Therefore a peer participates in two types of topology management: a
control structure in which peers make sure they are always connected control structure in which peers make sure they are always connected
in a mesh and a data delivery structure in which peers make sure data in a mesh and a data delivery structure in which peers make sure data
gets delivered to them in a tree structure. gets delivered to them in a tree structure.
To keep connected, each peer maintains communication with a small To keep connected, each peer maintains communication with a small
number of random neighbors and a complete list of members through a number of random neighbors and a complete list of members through a
gossip-like algorithm. When a new node joins, it gets a list of gossip-like algorithm. When a new node joins, it gets a list of
group members from the source. To look for a parent, it sends probe group members from the source. To look for a parent, it sends probe
request to a subset of the group members it obtained; evaluates them request to a subset of the group members it obtained; evaluates them
with respect to delay to the source, application throughput and link with respect to delay to the source, application throughput and link
bandwidth; and then chooses from among them a candidate parent that bandwidth; and then chooses from among them a candidate parent that
is not a descendant and is not saturated. In addition to using RTT- is not a descendant and is not saturated. In addition to using RTT-
probes, consisting of 1-Kbyte transfers to detect bottleneck probes, consisting of 1-Kbyte transfers to detect bottleneck
bandwidth, performance history of previously chosen parent is also bandwidth, a node also considers the performance history of previously
considered. The peer also avoids probing hosts with low bottleneck chosen parent. The peer also avoids probing hosts that have low
bandwidth. bandwidth or are bottlenecked.
When a peer leaves normally, it notifies its neighboring peers and When a peer leaves normally, it notifies its neighboring peers and
the neighboring peers propagate the departing peer info. At the same the neighboring peers propagate the departing peer info. At the same
time, the departing peer continues to forward packets for some time time, the departing peer continues to forward packets for some time
to minimize transient packet loss. When a peer leaves due to to minimize transient packet loss. When a peer leaves due to
failure, active peers detect the departure of the peer through its failure, active peers detect the departure of the peer through its
non-responsiveness to their probe messages. Active peers that non-responsiveness to their probe messages. Active peers that
detected the loss then propagate the departed peer info. A departed detected the loss then propagate the departed peer info. A departed
peer list that is flushed after a sufficient amount of time has peer list that is flushed after a sufficient amount of time has
passed keeps track of leaving and failed peers. The list enables passed keeps track of leaving and failed peers. The list enables
skipping to change at page 26, line 34 skipping to change at page 26, line 34
video streams and lower quality video being higher than quality video streams and lower quality video being higher than quality
video. Moreover, bit-rates of stream are adapted to the peer video. Moreover, bit-rates of stream are adapted to the peer
performance capability. performance capability.
3.3. Hybrid P2P streaming system 3.3. Hybrid P2P streaming system
3.3.1. New Coolstreaming 3.3.1. New Coolstreaming
The Coolstreaming, first released in summer 2004 with a mesh-based The Coolstreaming, first released in summer 2004 with a mesh-based
structure, arguably represented the first successful large-scale P2P structure, arguably represented the first successful large-scale P2P
live streaming. As the above analysis, it has poor delay performance live streaming. As in the above analysis, it has poor delay
and high overhead associated each video block transmission. After performance and high overhead associated each video block
that, New coolstreaming[New CoolStreaming] adopts a hybrid mesh and transmission. To improve the situation, New coolstreaming [New
tree structure with hybrid pull and push mechanism. All the peers CoolStreaming] adopts a hybrid mesh and tree structure with hybrid
are organized into mesh-based topology in the similar way like pplive pull and push mechanism. All the peers are organized into a
to ensure high reliability. mesh-based topology similar to PPLive to ensure high reliability.
Besides, content delivery mechanism is the most important part of New Besides, content delivery mechanism is the most important part of New
Coolstreaming. Fig.8 is the content delivery architecture. The Coolstreaming. Fig.8 is the content delivery architecture. The
video stream is divided into blocks with equal size, in which each video stream is divided into blocks with equal size, in which each
block is assigned a sequence number to represent its playback order block is assigned a sequence number to represent its playback order
in the stream. We divide each video stream into multiple sub-streams in the stream. Each video stream is further divided into multiple
without any coding, in which each node can retrieve any sub-stream sub-streams without any coding, allowing each node to retrieve any
independently from different parent nodes. This subsequently reduces sub-stream independently from different parent nodes. This
the impact to content delivery due to a parent departure or failure. consequently reduces the impact to content delivery due to a parent
The details of hybrid push and pull content delivery scheme are shown departure or failure. The details of hybrid push and pull content
in the following: delivery scheme are shown in the following:
(1) A node first subscribes to a sub-stream by connecting to one of (1) A node first subscribes to a sub-stream by connecting to one of
its partners via a single request (pull) in BM, the requested its partners via a single request (pull) in BM to the requested
partner, i.e., the parent node.( The node can subscribe more sub- partner, i.e., the parent node.( The node can subscribe to more than
streams to its partners in this way to obtain higher play quality.) one sub-stream from its partners to obtain higher play quality.)
(2) The selected parent node will continue pushing all blocks in need (2) The selected parent node will continue pushing all blocks
of the sub-stream to the requested node. of the requested sub-stream to the requesting node.
This not only reduces the overhead associated with each video block This not only reduces the overhead associated with each video block
transfer, but more importantly, significantly reduces the timing transfer, but more importantly, significantly reduces the delay
involved in retrieving video content. incurred in retrieving video content.
------------------------------ ------------------------------
| +---------+ | | +---------+ |
| | Tracker | | | | Tracker | |
| +---------+ | | +---------+ |
| | | | | |
| | | | | |
| +---------------------+ | | +---------------------+ |
| | Content server | | | | Content server | |
| +---------------------+ | | +---------------------+ |
|------------------------------ |------------------------------
skipping to change at page 27, line 42 skipping to change at page 27, line 42
+---------+ +---------+ +---------+ +---------+
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| Peer2 | | Peer3 | | Peer1 | | Peer3 | | Peer2 | | Peer3 | | Peer1 | | Peer3 |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Figure 8 Content Delivery Architecture Figure 8 Content Delivery Architecture
The following sections describe Coolstreaming QoS related features, The following sections describe Coolstreaming QoS related features,
extracted mostly from [CS1-Bo] and [CS2-Xie]. extracted mostly from [Bo] and [Xie].
The basic components of Coolstreaming consist of the source, The basic components of Coolstreaming consist of the source,
bootstrap node, web server, log server, media servers, and peers. bootstrap node, web server, log server, media servers, and peers.
Three basic modules in a peer help it maintain a partial view of the Three basic modules in a peer help it maintain a partial view of the
overlay (Membership Manager); establish and maintain partnership with overlay (Membership Manager); establish and maintain partnership with
other peers with which Buffer Maps indicating available video other peers using Buffer Maps to indicate available video
content, are exchanged (Partnership Manager),; and manage data content for exchange (Partnership Manager); and manage data
delivery, retrieval, and play out (Stream Manager). delivery, retrieval and play out (Stream Manager).
In building the overlay topology, a newly arrived peer contacts the In building the overlay topology, a newly arrived peer contacts the
bootstrap node for a list of nodes and stores it in its own mCache. bootstrap node for a list of nodes and stores it in its own mCache.
From the stored list, it selects nodes randomly to forms partnership From the stored list, it selects nodes randomly to forms partnership
and then parent-children relationship, where a partnership between and then parent-children relationship, where a partnership between
two nodes exists when only block availability information is two nodes exists when only block availability information is
exchanged between them, and a parent-children relationship exists exchanged between them, and a parent-children relationship exists
when, in addition to being partner, video content is also exchanged. when, in addition to being partner, video content is also exchanged.
Video content is processed for ease of delivery, retrieval, storage, Video content is processed for ease of delivery, retrieval, storage
and play out. To manage content delivery, a video stream is divided and play out. To manage content delivery, a video stream is divided
into blocks with equal size, each of which is assigned a sequence into blocks with equal size, each of which is assigned a sequence
number to represent its playback order in the stream. Each block is number to represent its playback order in the stream. Each block is
further divided into K sub-blocks and the set of ith sub-blocks of further divided into K sub-blocks and the set of ith sub-blocks of
all blocks constitutes the ith sub-stream of the video stream, where all blocks constitutes the ith sub-stream of the video stream, where
i is the value bigger than 0 and less than K+1. To retrieve video i is a value bigger than 0 and less than K+1. To retrieve video
content, a node receives at most K distinct sub-streams from its content, a node receives at most K distinct sub-streams from its
parent nodes. To store retrieved sub-streams, a node uses a double parent nodes. To store retrieved sub-streams, a node uses a double
buffering scheme having a synchronization buffer and a cache buffer. buffering scheme having a synchronization buffer and a cache buffer.
The synchronization buffer stores the received sub-blocks of each The synchronization buffer stores the received sub-blocks of each
sub-stream according to the associated block sequence number of the sub-stream according to the associated block sequence number of the
video stream. The cache buffer then picks up the sub-blocks video stream. The cache buffer then picks up the sub-blocks
according to the associated sub-stream index of each ordered block. according to the associated sub-stream index of each ordered block.
To advertise the availability of the latest block of different sub- To advertise the availability of the latest block of different sub-
streams in its buffer, a node uses a Buffer Map which is represented streams in its buffer, a node uses a Buffer Map which is represented
by two vectors of K elements each. Each entry of the first vector by two vectors of K elements each. Each entry of the first vector
indicates the block sequence number of the latest received sub- indicates the block sequence number of the latest received sub-
stream, and each bit entry of the second vector if set indicates the stream, and each bit entry of the second vector if set indicates the
index of the sub-stream that is being requested. block sequence index of the sub-stream that is being requested.
For data delivery, a node uses a hybrid push and pull scheme with For data delivery, a node uses a hybrid push and pull scheme with
randomly selected partners. A node having requested one or more randomly selected partners. A node having requested one or more
distinct sub-streams from a partner as indicated in its first Buffer distinct sub-streams from a partner as indicated in its first Buffer
Map will continue to receive the sub-streams of all subsequent blocks Map will continue to receive the sub-streams of all subsequent blocks
from the same partner until future conditions cause the partner to do from the same partner until future conditions cause the partner to do
otherwise. Moreover, users retrieve video indirectly from the source otherwise. Moreover, users retrieve video indirectly from the source
through a number of strategically located servers. through a number of strategically located servers.
To keep the parent-children relationship above a certain level of To keep the parent-children relationship above a certain level of
quality, each node constantly monitors the status of the on-going quality, each node constantly monitors the status of the on-going
sub-stream reception and re-selects parents according to sub-stream sub-stream reception and re-selects parents according to sub-stream
availability patterns. Specifically, if a node observes that the availability patterns. Specifically, if a node observes that the
block sequence number of the sub-stream of a parent is much smaller block sequence number of the sub-stream of a parent is much smaller
than any of its other partners!_ by a predetermined amount, then the than any of its other partners by a predetermined amount, the
node concludes that the parent is lagging sufficiently behind and node then concludes that the parent is lagging sufficiently behind and
needs to be replaced. Furthermore, a node also evaluates the maximum needs to be replaced. Furthermore, a node also evaluates the maximum
and minimum of the block sequence numbers in its synchronization and minimum of the block sequence numbers in its synchronization
buffer to determine if any parent is lagging behind the rest of its buffer to determine if any parent is lagging behind the rest of its
parents and thus needs also to be replaced. parents and thus needs also to be replaced.
4. A common P2P Streaming Process Model 4. A common P2P Streaming Process Model
As shown in Figure 8, a common P2P streaming process can be As shown in Figure 8, a common P2P streaming process can be
summarized based on Section 3: summarized based on Section 3:
skipping to change at page 30, line 15 skipping to change at page 30, line 15
Canviva, Tracker directs new peers to find parent nodes and the data Canviva, Tracker directs new peers to find parent nodes and the data
flows from parent to child only. flows from parent to child only.
5. Security Considerations 5. Security Considerations
This document does not consider security issues. It follows the This document does not consider security issues. It follows the
security consideration in [draft-zhang-ppsp-problem-statement]. security consideration in [draft-zhang-ppsp-problem-statement].
6. Acknowledgments 6. Acknowledgments
We would like to acknowledge Jiang xingfeng for providing good ideas We would like to acknowledge Jiang XingFeng for providing good ideas
for this document. for this document.
7. Informative References 7. Informative References
[PPLive] "www.pplive.com". [PPLive] "www.pplive.com".
[PPStream] [PPStream]
"www.ppstream.com". "www.ppstream.com".
[CNN] "www.cnn.com". [CNN] "www.cnn.com".
[OctoshapeWeb] [OctoshapeWeb]
"www.octoshape.com". "www.octoshape.com".
[Joost-Experiment] [Joost-Experiment]
Lei, Jun, et al., "An Experimental Analysis of Joost Peer- Lei, Jun, et al., "An Experimental Analysis of Joost Peer-
to-Peer VoD Service". to-Peer VoD Service". Dec. 2009.
[Sigcomm_P2P_Streaming] [Sigcomm_P2P_Streaming]
Huang, Yan, et al., "Challenges, Design and Analysis of a Huang, Yan, et al., "Challenges, Design and Analysis of a
Large-scale P2P-VoD System", 2008. Large-scale P2P-VoD System", 2008.
[Octoshape] [Octoshape]
Alstrup, Stephen, et al., "Introducing Octoshape-a new Alstrup, Stephen, et al., "Introducing Octoshape-a new
technology for large-scale streaming over the Internet". technology for large-scale streaming over the Internet".
[Zattoo] "http: //zattoo.com/". [Zattoo] "http: //zattoo.com/".
[Conviva] "http://www.rinera.com/". [Conviva] "http://www.rinera.com/".
[ESM04] Zhang, Hui., "End System Multicast, [ESM04] Zhang, Hui., "End System Multicast,
http://www.cs.cmu.edu/~hzhang/Talks/ESMPrinceton.pdf", http://www.cs.cmu.edu/~hzhang/Talks/ESMPrinceton.pdf",
May . May 2004.
[Survey] Liu, Yong, et al., "A survey on peer-to-peer video [Survey] Liu, Yong, et al., "A survey on peer-to-peer video
streaming systems", 2008. streaming systems", 2008.
[draft-zhang-alto-traceroute-00] [draft-zhang-alto-traceroute-00]
"www.ietf.org/internet-draft/ "www.ietf.org/internet-draft/
draft-zhang-alto-traceroute-00.txt". draft-zhang-alto-traceroute-00.txt".
[P2PStreamingSurvey] [P2PStreamingSurvey]
Zong, Ning, et al., "Survey of P2P Streaming", Nov. 2008. Zong, Ning, et al., "Survey of P2P Streaming", Nov. 2008.
skipping to change at page 31, line 28 skipping to change at page 31, line 28
[Challenge] [Challenge]
Li, Bo, et al., "Peer-to-Peer Live Video Streaming on the Li, Bo, et al., "Peer-to-Peer Live Video Streaming on the
Internet: Issues, Existing Approaches, and Challenges", Internet: Issues, Existing Approaches, and Challenges",
June 2007. June 2007.
[NewCoolstreaming] [NewCoolstreaming]
Li, Bo, et al., "Inside the New Coolstreaming: Li, Bo, et al., "Inside the New Coolstreaming:
Principles,Measurements and Performance Implications", Principles,Measurements and Performance Implications",
Apr. 2008. Apr. 2008.
[JO2-Moreira] [Moreira]
Moreira, J, et al., "IEEE Network Operations and Moreira, J, et al., " A step towards understanding Joost
Management Symposium", Apr. 2008. IPTV", Apr. 2008.
[JO7-Joost Network Architecture] [Joost Network Architecture]
"Joost Network Architecture, "Joost Network Architecture,
http://scaryideas.com/content/2362/". http://scaryideas.com/content/2362/".
[OC2-Alstrup] [Alstrup]
Alstrup, S, et al., "Octoshape "C a new technology for Alstrup, S, et al., "Octoshape a new technology for
large-scale streaming over the Internet", 2005. large-scale streaming over the Internet", 2005.
[OC3-Alstrup] [Alstrup]
Alstrup, S, et al., "Grid live streaming to millions", Alstrup, S, et al., "Grid live streaming to millions",
2006. 2006.
[PL3-Hei] Hei, X, et al., "Insights into PPLive: A measurement study [Hei]
Hei, X, et al., "Insights into PPLive: A measurement study
of a large-scale P2P IPTV system", May 2006. of a large-scale P2P IPTV system", May 2006.
[PL5-Vu] Vu, L, et al., "Understanding Overlay Characteristics of a [Vu]
Vu, L, et al., "Understanding Overlay Characteristics of a
Large-Scale Peer-to-Peer IPTV System", November 2010. Large-Scale Peer-to-Peer IPTV System", November 2010.
[PL6-Horvath] [Horvath]
"". Horvath, A, et al., "Dissecting PPLive, SopCast, TVAnt", 2008.
[SC3-Horvath]
"".
[TV3-Horvath]
Horvath, A, et al., "Dissecting PPLive, SopCast, TVAnt".
[PL7-Liu] Liu, Y, et al., "A Case Study of Traffic Locality in [Liu]
Internet P2P Live Streaming Systems". Liu, Y, et al., "A Case Study of Traffic Locality in
Internet P2P Live Streaming Systems", June 2009.
[PS3-Li] Li, C, et al., "Measurement Based PPStream client behavior [Li]
Li, C, et al., "Measurement Based PPStream client behavior
analysis", 2009. analysis", 2009.
[PS4-Jia] Jia, J, et al., "Characterizing PPStream across Internet", [Jia]
Jia, J, et al., "Characterizing PPStream across Internet",
2007. 2007.
[PS5-Wei] Wei, T, et al., "Study of PPStream Based on Measurement", [Wei]
Wei, T, et al., "Study of PPStream Based on Measurement",
2008. 2008.
[SC1-Ali] Ali, S, et al., "Measurement of Commercial Peer-to-Peer [Ali]
Ali, S, et al., "Measurement of Commercial Peer-to-Peer
Live Video Streaming", Aug 2006. Live Video Streaming", Aug 2006.
[SC2-Ciullo] [Ciullo]
"". Ciullo, D, et al., "Network Awareness of P2P Live
[TV2] Ciullo, D, et al., "Network Awareness of P2P Live
Streaming Applications: A Measurement Study", Aug 2010. Streaming Applications: A Measurement Study", Aug 2010.
[SC4-Fallica] [Fallica]
Fallica, B, et al., "On the Quality of Experience of Fallica, B, et al., "On the Quality of Experience of
SopCast", Aug 2008. SopCast", Aug 2008.
[SC5-Sentinelli] [Sentinelli]
Sentinelli, A, et al., "Will IPTV Ride the Peer-to-Peer Sentinelli, A, et al., "Will IPTV Ride the Peer-to-Peer
Stream?", June 2007. Stream?", June 2007.
[SC6-Silverston] [Silverston]
Silverston, T, et al., "Traffic analysis of peer-to-peer Silverston, T, et al., "Traffic analysis of peer-to-peer
IPTV communities", 2009. IPTV communities", 2009.
[SC7-Tang] [Tang]
Tang, S, et al., "Topology dynamics in a P2PTV network", Tang, S, et al., "Topology dynamics in a P2PTV network",
2009. 2009.
[TV1-Alessandria] [Alessandria]
Alessandria, E, et al., "P2P-TV Systems under Adverse Alessandria, E, et al., "P2P-TV Systems under Adverse
Network Conditions: a Measurement Study", 2009. Network Conditions: a Measurement Study", 2009.
[ZT1-Chang] [Chang]
Chang, H, et al., "Live streaming performance of the Chang, H, et al., "Live streaming performance of the
Zattoo network", 2009. Zattoo network", 2009.
[PC1-Deshpande] [Deshpande]
Deshpande, H, et al., "Streaming Live Media over a Peer- Deshpande, H, et al., "Streaming Live Media over a Peer-
to-Peer Network", August 2001. to-Peer Network", August 2001.
[PC2-http] [Desphande]
"http://arbor.ee.ntu.edu.tw/archive/p2p/p2p/showDoc2.pdf". Desphande, H, et al., " Streaming Live Media over Peers,
http://ilpubs.stanford.edu:8090/863/", December 2008.
[PC3-http]
"http://ilpubs.stanford.edu:8090/863/".
[CVV1-Zhang]
Zhang, H, et al., "End System Multicast", May 2004.
[CVV4-Chu] [Chu1]
Chu, Y, et al., "A Case for End System Multicast", Chu, Y, et al., "A Case for End System Multicast",
June 2000. June 2000.
[CVV5-Chu] [Chu2]
Chu, Y, et al., "Early Experience with an Internet Chu, Y, et al., "Early Experience with an Internet
Broadcast System Based on Overlay Multicast", June 2004. Broadcast System Based on Overlay Multicast", June 2004.
[CVV6-Chu] [Chu3]
Chu, Y, et al., "Narada is a self-organizing, overlay- Chu, Y, et al., "Narada is a self-organizing, overlay-
based protocol for achieving multicast without network based protocol for achieving multicast without network
support", Aug 2001. support", Aug 2001.
[CS1-Bo] Li, B, et al., "Inside the New Coolstreaming: Principles, [Bo]
Li, B, et al., "Inside the New Coolstreaming: Principles,
Measurements and Performance Implications", 2008. Measurements and Performance Implications", 2008.
[CS2-Xie] Xie, S, et al., "Coolstreaming: Design, Theory, and [Xie]
Xie, S, et al., "Coolstreaming: Design, Theory, and
Practice", 2007. Practice", 2007.
Authors' Addresses Authors' Addresses
Gu Yingjie Gu Yingjie
Huawei Huawei
Baixia Road No. 91 Baixia Road No. 91
Nanjing, Jiangsu Province 210001 Nanjing, Jiangsu Province 210001
P.R.China P.R.China
 End of changes. 141 change blocks. 
283 lines changed or deleted 273 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/