One document matched: draft-ietf-ppsp-survey-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC4330 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4330.xml">
<!ENTITY RFC4981 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4981.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY I-D.ietf-p2psip-sip SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-sip.xml">
<!ENTITY I-D.ietf-p2psip-base SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-base.xml">
<!ENTITY I-D.song-p2psip-security-eval SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.song-p2psip-security-eval.xml">
<!ENTITY I-D.bryan-p2psip-app-scenarios SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryan-p2psip-app-scenarios.xml">
<!ENTITY I-D.bryan-p2psip-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryan-p2psip-requirements.xml">
<!ENTITY I-D.zheng-p2psip-diagnose SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zheng-p2psip-diagnose.xml">
<!ENTITY I-D.matuszewski-p2psip-security-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.matuszewski-p2psip-security-requirements.xml">
<!ENTITY I-D.baset-p2psip-p2pp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baset-p2psip-p2pp.xml">
<!ENTITY I-D.ietf-mmusic-ice SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice.xml">
<!ENTITY I-D.ietf-behave-rfc3489bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-rfc3489bis.xml">
<!ENTITY I-D.ietf-p2psip-concepts SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-p2psip-concepts.xml">
]>
<rfc category="std" docName="draft-ietf-ppsp-survey-00" ipr="trust200902"
submissionType="IETF" updates="" xml:lang="">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<front>
<title>Survey of P2P Streaming Applications</title>
<author fullname="Gu Yingjie" initials="Y.J. " surname="Gu">
<organization>Huawei</organization>
<address>
<postal>
<street>Baixia Road No. 91</street>
<city>Nanjing</city>
<region>Jiangsu Province</region>
<code>210001</code>
<country>P.R.China</country>
</postal>
<phone>+86-25-56624760</phone>
<facsimile>+86-25-56624702</facsimile>
<email>guyingjie@huawei.com</email>
</address>
</author>
<author fullname="Zong Ning" initials="N." surname="Zong">
<organization>Huawei</organization>
<address>
<postal>
<street>Baixia Road No. 91</street>
<city>Nanjing</city>
<region>Jiangsu Province</region>
<code>210001</code>
<country>P.R.China</country>
</postal>
<phone>+86-25-56624760</phone>
<facsimile>+86-25-56624702</facsimile>
<email>zongning@huawei.com</email>
</address>
</author>
<author fullname="Hui Zhang" initials="Hui" surname="Zhang">
<organization>NEC Labs America.</organization>
<address>
<email>huizhang@nec-labs.com</email>
</address>
</author>
<author fullname="Zhang Yunfei" initials="Yunfei" surname="Zhang">
<organization>China Mobile</organization>
<address>
<email>zhangyunfei@chinamobile.com</email>
</address>
</author>
<author fullname="Lei Jun" initials="J." surname="Lei">
<organization>University of Goettingen</organization>
<address>
<phone>+49 (551) 39172032</phone>
<email>lei@cs.uni-goettingen.de</email>
</address>
</author>
<author fullname="Gonzalo Camarillo" initials="Gonzalo"
surname="Camarillo">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<email>Gonzalo.Camarillo@ericsson.com</email>
</address>
</author>
<author fullname="Liu Yong" initials="Yong" surname="Liu">
<organization>Polytechnic University</organization>
<address>
<email>yongliu@poly.edu</email>
</address>
</author>
<date day="27" month="February" year="2011" />
<area>Transport Area</area>
<workgroup>PPSP</workgroup>
<keyword>Survey</keyword>
<keyword>P2P Streaming</keyword>
<abstract>
<t>This document presents a survey of popular Peer-to-Peer streaming
applications on the Internet. We focus on the Architecture and Peer
Protocol/Tracker Signaling Protocol description in the presentation, and
study a selection of well-known P2P streaming systems, including Joost,
PPlive, andother popular existing systems. Through the survey, we
summarize a common P2P streaming process model and the correspondent
signaling process for P2P Streaming Protocol standardization.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Toward standardizing the signaling protocols used in today's
Peer-to-Peer (P2P) streaming applications, we surveyed several popular
P2P streaming systems regarding their architectures and signaling
protocols between peers, as well as, between peers and trackers. The
studied P2P streaming systems, running worldwide or domestically,
include such as PPLive, Joost, Cybersky-TV, and Octoshape. This document
does not intend to cover all design options of P2P streaming
applications. Instead, we choose a representative set of applications
and focus on the respective signaling characteristics of each kind.
Through the survey, we generalize a common streaming process model from
those P2P streaming systems, and summarize the companion signaling
process as the base for P2P Streaming Protocol (PPSP)
standardization.</t>
</section>
<section title="Terminologies and concepts" toc="default">
<t>Chunk: A chunk is a basic unit of partitioned streaming media, which
is used by a peer for the purpose of storage, advertisement and exchange
among peers [Sigcomm:P2P streaming].</t>
<t>Content Distribution Network (CDN) node: A CDN node refers to a
network entity that usually is deployed at the network edge to store
content provided by the original servers, and serves content to the
clients located nearby topologically.</t>
<t>Live streaming: The scenario where all clients receive streaming
content for the same ongoing event. The lags between the play points of
the clients and that of the streaming source are small..</t>
<t>P2P cache: A P2P cache refers to a network entity that caches P2P
traffic in the network, and either transparently or explicitly
distributes content to other peers.</t>
<t>P2P streaming protocols: P2P streaming protocols refer to multiple
protocols such as streaming control, resource discovery, streaming data
transport, etc. which are needed to build a P2P streaming system.</t>
<t>Peer/PPSP peer: A peer/PPSP peer refers to a participant in a P2P
streaming system. The participant not only receives streaming content,
but also stores and uploads streaming content to other participants.</t>
<t>PPSP protocols: PPSP protocols refer to the key signaling protocols
among various P2P streaming system components, including the tracker and
peers.</t>
<t>Swarm: A swarm refers to a group of clients (i.e. peers) sharing the
same content (e.g. video/audio program, digital file, etc) at a given
time.</t>
<t>Tracker/PPSP tracker: A tracker/PPSP tracker refers to a directory
service which maintains the lists of peers/PPSP peers storing chunks for
a specific channel or streaming file, and answers queries from
peers/PPSP peers.</t>
<t>Video-on-demand (VoD): A kind of application that allows users to
select and watch video content on demand</t>
</section>
<section title="Survey of P2P streaming system">
<t>In this section, we summarize some existing P2P streaming systems.
The construction techniques used in these systems can be largely
classified into two categories: tree-based and mesh-based
structures.</t>
<t>Tree-based structure: Group members self-organize into a tree
structure, based on which group management and data delivery is
performed. Such structure and push-based content delivery have small
maintenance cost and good scalability and low delay in retrieving the
content(associated with startup delay) and can be easily implemented.
However, it may result in low bandwidth usage and less reliability.</t>
<t>Mesh-based structure: In contrast to tree-based structure, a mesh
uses multiple links between any two nodes. Thus, the reliability of data
transmission is relatively high. Besides, multiple links results in high
bandwidth usage. Nevertheless, the cost of maintaining such mesh is much
larger than that of a tree, and pull-based content delivery lead to high
overhead associated each video block transmission, in particular the
delay in retrieving the content.</t>
<t>Hybrid structure: Combine tree-based and mesh-based structure,
combine pull-based and push-based content delivery to utilize the
advantages of two structures. It has high reliability as much as
mesh-based structure, lower delay than mesh-based structure, lower
overhead associated each video block transmission and high topology
maintenance cost as much as mesh-based structure.</t>
<section title="Mesh-based P2P streaming systems">
<section title="Joost">
<t>Joost announced to give up P2P technology on its desktop version
last year, though it introduced a flash version for browsers and
iPhone application. The key reason why Joost shut down its desktop
version 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 worthwhile to understand how Joost works. The peer
management and data transmission in Joost mainly relies on
mesh-based structure.</t>
<t>The three key components of Joost are servers, super nodes and
peers. There are five types of servers: Tracker server, Version
server, Backend server, Content server and Graphics server. The
architecture of Joost system is shown in Figure 1.</t>
<t>First, we introduce the functionalities of Joost's key components
through three basic phases. Then we will discuss the Peer protocol
and Tracker protocol of Joost.</t>
<t>Installation: Backend server is involved in the installation
phase. Backend server provides peer with an initial channel list in
a SQLite file. No other parameters, such as local cache, node ID, or
listening port, are configured in this file.</t>
<t>Bootstrapping: In case of a newcomer, Tracker server provides
several super node addresses and possibly some content server
addresses. Then the peer connects Version server for the latest
software version. Later, the peer starts to connect some super nodes
to obtain the list of other available peers and begins streaming
video contents. Different from Skype [skype], super nodes in Joost
only deal with control and peer management traffic. They do not
relay/forward any media data.</t>
<t>Channel switching: Super nodes are responsible for redirecting
clients to content server or peers.</t>
<t>Peers communicate with servers over HTTP/HTTPs and with super
nodes/other peers over UDP.</t>
<t>Tracker Protocol: Because super nodes here are responsible for
providing the peerlist/content servers to peers, protocol used
between tracker server and peers is rather simple. Peers get the
addresses of super nodes and content servers from Tracker Server
over HTTP. After that, Tracker sever will not appear in any stage,
e.g. channel switching, VoD interaction. In fact, the protocol
spoken between peers and super nodes is more like what we normally
called "Tracker Protocol". It enables super nodes to check peer
status, maintain peer lists for several, if not all, channels. 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.</t>
<t>Peers will communicate with super nodes in some scenarios using
Tracker Protocol.</t>
<t>1. When a peer starts Joost software, after the installation and
bootstrapping, the peer will communicate with one or several super
nodes to get a list of available peers/content servers.</t>
<t>2. For on-demand video functions, super nodes periodically
exchange small UDP packets for peer management purpose.</t>
<t>3. When switching between channels, peers contact super nodes and
the latter help the peers find available peers to fetch the
requested media data.</t>
<t>Peer Protocol: The following investigations are mainly motivated
from [Joost- experiment ], in which a data-driven reverse-engineer
experiments are performed. We omitted the analysis process and
directly show the conclusion. Media data in Joost is split into
chunks and then encrypted. Each chunk is packetized with about 5-10
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
list to find out what chunks they have. Then the peer makes decision
about from which peers to get the chunks. No peer capability
information is exchanged in the Peer Protocol.</t>
<figure>
<artwork name="Architecture of Joost system"> +---------------+ +-------------------+
| Version Server| | Tracker Server |
+---------------+ +-------------------+
\ |
\ |
\ | +---------------+
\ | |Graphics Server|
\ | +---------------+
\ | |
+--------------+ +-------------+ +--------------+
|Content Server|--------| Peer1 |--------|Backend Server|
+--------------+ +-------------+ +--------------+
|
|
|
|
+------------+ +---------+
| Super Node |-------| Peer2 |
+------------+ +---------+
Figure 1, Architecture of Joost system</artwork>
</figure>
</section>
<section title="Octoshape">
<t>CNN has been working with a P2P Plug-in, from a Denmark-based
company Octoshape, to broadcast its living streaming. Octoshape
helps CNN serve a peak of more than a million simultaneous viewers.
It has also provided several innovative delivery technologies such
as loss resilient transport, adaptive bit rate, adaptive path
optimization and adaptive proximity delivery. Figure 2 depicts the
architecture of the Octoshape system.</t>
<t>Octoshape maintains a mesh overlay topology. Its overlay topology
maintenance scheme is similar to that of P2P file-sharing
applications, such as BitTorrent. There is no Tracker server in
Octoshape, thus no Tracker Protocol is required. Peers obtain live
streaming from content servers and peers over Octoshape Protocol.
Several data streams are constructed from live stream. No data
streams are identical and any number K of data streams can
reconstruct the original live stream. The number K is based on the
original media playback rate and the playback rate of each data
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,
instead of Broadcast server, which release server from large burden.
The number of data streams constructed in a particular peer equals
the number of peers downloading data from the particular peer, which
is constrained by the upload capacity of the particular peer. To get
the best performance, the upload capacity of a peer should be larger
than the playback rate of the live stream. If not, an artificial
peer may be added to deliver extra bandwidth.</t>
<t>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 book. The peer periodically probes/asks the peers in the
standby list to be sure that they are ready to take over if one of
the current senders stops or gets congested. [Octoshape]</t>
<t>Peer Protocol: The live stream is firstly sent to a few peers in
the network and then be spread to the rest. When a peer joins a
channel, it notifies all the other peers about its presence over
Peer Protocol, which will drive the others to add it into their
address books. Although [Octoshape] declares that each peer records
all the peers joining the channel, we suspect that not all the peers
are recorded, considering the notification traffic will be large and
peers will be busy with recording when a popular program starts in a
channel and lots of peers switch to this channel. Maybe some
geographic or topological neighbors are notified and the peer gets
its address book from these neighbors.</t>
<t>Peer Protocol: The live stream is firstly sent to a few peers in
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
using Peer Protocol, which will drive the others to add it into
their address books. Although [Octoshape] declares that each peer
records all the peers joining the channel, we suspect that not all
the peers are recorded, considering the notification traffic will be
large and peers will be busy with recording when a popular program
starts in a channel and lots of peers switch to this channel. Maybe
some geographic or topological neighbors are notified and the peer
gets its address book from these nearby neighbors.</t>
<t>The peer sends requests to some selected peers for the live
stream and the receivers answers OK or not according to their upload
capacity. The peer continues sending requests to peers until it
finds enough peers to provide the needed data streams to redisplay
the original live stream. The details of Octoshape are (not?)
disclosed yet, we hope someone else can provide much specific
information.</t>
<figure>
<artwork name="Architecture of Octoshape system"> +------------+ +--------+
| Peer 1 |---| Peer 2 |
+------------+ +--------+
| \ / |
| \ / |
| \ |
| / \ |
| / \ |
| / \ |
+--------------+ +-------------+
| Peer 4 |----| Peer3 |
+--------------+ +-------------+
*****************************************
|
|
+---------------+
| Content Server|
+---------------+
Figure 2, Architecture of Octoshape system</artwork>
</figure>
</section>
<section title="PPLive">
<t>PPLive is one of the most popular P2P streaming software in
China. It has two major communication protocols. One is Registration
and peer discovery protocol, i.e. Tracker Protocol, and the other is
P2P chunk distribution protocol, i.e. Peer Protocol. Figure 3 shows
the architecture of PPLive.</t>
<t>Tracker Protocol: First, a peer gets the channel list from the
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
this channel.</t>
<t>Peer Protocol: The peer contacts the peers in its peerlist to get
additional peerlists, which are aggregated with its existing list.
Through this list, peers can maintain a mesh for peer management and
data delivery.</t>
<t>For the video-on-demand (VoD) operation, because different peers
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
others. Some of these chunks may be chunks that have been recently
played; the remaining chunks are chunks scheduled to be played in
the next few minutes. Peers upload chunks to each other. To this
end, peers send to each other “buffer-map” messages; a
buffer-map message indicates which chunks a peer currently has
buffered and can share. 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 indicating which chunks are available
(starting with the chunk designated by the offset). PPlive transfer
Data over UDP.</t>
<t>Video Download Policy of PPLive</t>
<t><list>
<t>1 Top ten peers contribute to a major part of the download
traffic. Meanwhile, the top peer session is quite short compared
with the video session duration. This would suggest that PPLive
gets video from only a few peers at any given time, and switches
periodically from one peer to another;</t>
<t>2 PPLive can send multiple chunk requests for different
chunks to one peer at one time;</t>
</list></t>
<t>PPLive maintains a constant peer list with relatively small
number of peers. [P2PIPTV-measuring]</t>
<figure>
<artwork name="Architecture of PPlive system"> +------------+ +--------+
| Peer 2 |----| Peer 3 |
+------------+ +--------+
| |
| |
+--------------+
| Peer 1 |
+--------------+
|
|
|
+---------------+
| Tracker Server|
+---------------+
Figure 3, Architecture of PPlive system</artwork>
</figure>
</section>
<section title="Zattoo">
<t>Zattoo is P2P live streaming system which serves over 3 million
registered users over European countries [Zattoo].The system
delivers live streaming using a receiver-based, peer-division
multiplexing scheme. Zattoo reliabily streams media among peers
using the mesh structure.</t>
<t>Figure 4 depcits a typical procedure of single TV channel carried
over Zattoo network. First, Zattoo system broadcasts live TV,
captured from satellites, onto the Internet. Each TV channel is
delivered through a separate P2P network.</t>
<figure>
<artwork> -------------------------------
| ------------------ | --------
| | Broadcast | |---------|Peer1 |-----------
| | Servers | | -------- |
| Administrative Servers | -------------
| ------------------------ | | Super Node|
| | Authentication Server | | -------------
| | Rendezvous Server | | |
| | Feedback Server | | -------- |
| | Other Servers | |---------|Peer2 |----------|
| ------------------------| | --------
------------------------------|
Figure 4, Basic architecture of Zattoo system</artwork>
</figure>
<t>Tracker(Rendezvous Server) Protocol: In order to receive the
signal the requested channel, registered users are required to be
authenticated through Zattoo Authentication Server. Upon
authentication, users obtain a ticket with specific lifetime. Then,
users contact Rendezvous Server with the ticket and identify of
interested TV channel. In return, the Rendezvous Server sends back a
list joined peers carrying the channel.</t>
<t>Peer Protocol: Similar to aforementioned procedures in Joost,
PPLive, a new Zattoo peer requests to join an existing peer among
the peer list. Upon the availability of bandwidth, requested peer
decides how to multiplex a stream onto its set of neighboring peers.
When packets arrive at the peer, sub-streams are stored for
reassembly constructing the full stream.</t>
<t>Note Zattoo relies on Bandwdith Estimation Server to initially
estimate the amount of available uplink bandwith at a peer. Once a
peer starts to forward substream to other peers, it receives QoS
feedback from other receivers if the quality of sub-stream drops
below a threshold.</t>
</section>
<section title="PPStream">
<t>The system architecture and working flows of PPStream is similar
to PPLive. PPStream transfers data using mostly TCP, only
occasionally UDP.</t>
<t>Video Download Policy of PPStream<list>
<t>1 Top ten peers do not contribute to a large part of the
download traffic. This would suggest that PPStream gets the
video from many peers simultaneously, and its peers have long
session duration;</t>
<t>2 PPStream does not send multiple chunk requests for
different chunks to one peer at one time;</t>
</list></t>
<t>PPStream maintains a constant peer list with relatively large
number of peers. [P2PIPTV-measuring]</t>
</section>
<section title="SopCast">
<t>The system architecture and working flows of SopCast is similar
to PPLive. SOPCast transfer data mainly using UDP, occasionally
TCP;</t>
<t>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 switches periodically between
provider peers. However, SOPCast seems to always need more than one
peer to get the video, while in PPLive a single peer could be the
only video provider;</t>
<t>SOPCast’s peer list can be as large as PPStream’s
peer list. But SOPCast’s peer list varies over time.
[P2PIPTV-measuring]</t>
</section>
<section title="TVants">
<t>The system architecture and working flows of TVants is similar to
PPLive. TVAnts is more balanced between TCP and UDP in data
transmission;</t>
<t>The system architecture and working flows of TVants is similar to
PPLive. TVAnts is more balanced between TCP and UDP in data
transmission;</t>
<t>TVAnts’ peer list is also large and varies over time.
[P2PIPTV-measuring]</t>
<t>We extract the common Main components and steps of PPLive,
PPStream, SopCast and TVants, which is shown in Figure 5.</t>
<figure>
<artwork name="Main components and steps of PPLive, PPStream, SopCast and Tvants"> +------------+
| Tracker |
/+------------+
/
/ +------+
1,2/ /|Peer 1|
/ / +------+
/ /3,4,6
+---------+/ +------+
|New Peer |---------------|Peer 2|
+---------+\ 4,6 +------+
|5 | \
|---| \ +------+
3,4,6 \|Peer 3|
+------+
Figure 5, Main components and steps of PPLive, PPStream, SopCast and Tvants</artwork>
</figure>
<t>The main steps are:<list>
<t>(1) A new peer registers with tracker / distributed hash
table (DHT) to join the peer group which shares a same channel /
media content;</t>
<t>(2) Tracker / DHT returns an initial peer list to the new
peer;</t>
<t>(3) The new peer harvests peer lists by gossiping (i.e.
exchange peer list) with the peers in the initial peer list to
aggregate more peers sharing the channel / media content;</t>
<t>(4) The new peer randomly (or with some guide) selects some
peers from its peer list to connect and exchange peer
information (e.g. buffer map, peer status, etc) with connected
peers to know where to get what data;</t>
<t>(5) The new peer decides what data should be requested in
which order / priority using some scheduling algorithm and the
peer information obtained in Step (4);</t>
<t>(6) The new peer requests the data from some connected
peers.</t>
</list></t>
</section>
</section>
<section title="Tree-based P2P streaming systems">
<section title="PeerCast">
<t>PeerCast adopts a Tree structure. The architecture of PeerCast is
shown in Figure 6.</t>
<t>Peers in one channel construct the Broadcast Tree and the
Broadcast server is the root of the Tree. A Tracker can be
implemented independently or merged in the Broadcast server. Tracker
in Tree based P2P streaming application selects the parent nodes for
those new peers who join in the Tree. A Transfer node in the Tree
receives and transfers data simultaneously.</t>
<t>Peer Protocol: The peer joins a channel and gets the broadcast
server 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 broadcast server has enough idle capability, it
will include the peer in its child-list. Otherwise, the broadcast
server will choose 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 that can server it.</t>
<t>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 receiver. A node in the tree will notify its status to its parent
periodically, and the latter will update its child-list according to
the received notifications.</t>
<figure>
<artwork name="Architecture of PeerCast system"> ------------------------------
| +---------+ |
| | Tracker | |
| +---------+ |
| | |
| | |
| +---------------------+ |
| | Broadcast server | |
| +---------------------+ |
|------------------------------
/ \
/ \
/ \
/ \
+---------+ +---------+
|Transfer1| |Transfer2|
+---------+ +---------+
/ \ / \
/ \ / \
/ \ / \
+---------+ +---------+ +---------+ +---------+
|Receiver1| |Receiver2| |Receiver3| |Receiver4|
+---------+ +---------+ +---------+ +---------+
Figure 6, Architecture of PeerCast system</artwork>
</figure>
</section>
<section title="Conviva">
<t>Conviva™[conviva] is a real-time media control platform for
Internet multimedia broadcasting. For its early prototype, End
System Multicast (ESM) [ESM04] is the underlying networking
technology on organizing and maintaining an overlay broadcasting
topology. Next we present the overview of ESM. ESM adopts a Tree
structure. The architecture of ESM is shown in Figure 7.</t>
<t>ESM has two versions of protocols: one for smaller scale
conferencing apps with multiple sources, and the other for larger
scale broadcasting apps with Single source. We focus on the latter
version in this survey.</t>
<t>ESM maintains a single tree for its overlay topology. Its basic
functional components include two parts: a bootstrap protocol, a
parent selection algorithm, and a light-weight probing protocol for
tree topology construction and maintenance; a separate control
structure decoupled from tree, where a gossip-like algorithm is used
for each member to know a small random subset of group members;
members also maintain pathes from source.</t>
<t>Upon joining, a node gets a subset of group membership from the
source (the root node); it then finds parent using a parent
selection algorithm. The node uses light-weight probing heuristics
to a subset of members it knows, and evaluates remote nodes and
chooses a candidate parent. It also uses the parent selection
algorithm to deal with performance degradation due to node and
network churns.</t>
<t>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 children.</t>
<figure>
<artwork name="Architecture of ESM system"> ------------------------------
| +---------+ |
| | Tracker | |
| +---------+ |
| | |
| | |
| +---------------------+ |
| | Broadcast server | |
| +---------------------+ |
|------------------------------
/ \
/ \
/ \
/ \
+---------+ +---------+
| Peer1 | | Peer2 |
+---------+ +---------+
/ \ / \
/ \ / \
/ \ / \
+---------+ +---------+ +---------+ +---------+
| Peer3 | | Peer4 | | Peer5 | | Peer6 |
+---------+ +---------+ +---------+ +---------+
Figure 7, Architecture of ESM system</artwork>
</figure>
</section>
</section>
<section title="Hybrid P2P streaming system">
<section title="New Coolstreaming">
<t>The Coolstreaming, first released in summer 2004 with a
mesh-based structure, arguably represented the first successful
large-scale P2P live streaming. As the above analysis, it has poor
delay performance and high overhead associated each video block
transmission. After that, New coolstreaming[New CoolStreaming]
adopts a hybrid mesh and tree structure with hybrid pull and push
mechanism. All the peers are organized into mesh-based topology in
the similar way like pplive to ensure high reliability.</t>
<t>Besides, content delivery mechanism is the most important part of
New Coolstreaming. Fig.8 is the content delivery architecture. The
video stream is divided into blocks with equal size, in which each
block is assigned a sequence number to represent its playback order
in the stream. We divide each video stream into multiple sub-streams
without any coding, in which each node can retrieve any sub-stream
independently from different parent nodes. This subsequently reduces
the impact to content delivery due to a parent departure or failure.
The details of hybrid push and pull content delivery scheme are
shown in the following:</t>
<t>(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
partner, i.e., the parent node.( The node can subscribe more
sub-streams to its partners in this way to obtain higher play
quality.)</t>
<t>(2) The selected parent node will continue pushing all blocks in
need of the sub-stream to the requested node.</t>
<t>This not only reduces the overhead associated with each video
block transfer, but more importantly, significantly reduces the
timing involved in retrieving video content.</t>
<figure>
<artwork name="Architecture of PeerCast system"> ------------------------------
| +---------+ |
| | Tracker | |
| +---------+ |
| | |
| | |
| +---------------------+ |
| | Content server | |
| +---------------------+ |
|------------------------------
/ \
/ \
/ \
/ \
+---------+ +---------+
| Peer1 | | Peer2 |
+---------+ +---------+
/ \ / \
/ \ / \
/ \ / \
+---------+ +---------+ +---------+ +---------+
| Peer2 | | Peer3 | | Peer1 | | Peer3 |
+---------+ +---------+ +---------+ +---------+
Figure 8 Content Delivery Architecture
</artwork>
</figure>
</section>
</section>
</section>
<section title="A common P2P Streaming Process Model" toc="default">
<t>As shown in Figure 8, a common P2P streaming process can be
summarized based on Section 3:</t>
<t><list>
<t>1) When a peer wants to receive streaming content:<list>
<t>1.1) Peer acquires a list of peers/parent nodes from the
tracker.</t>
<t>1.2) Peer exchanges its content availability with the peers
on the obtained peer list, or requests to be adopted by the
parent nodes.</t>
<t>1.3) Peer identifies the peers with desired content, or the
available parent node.</t>
<t>1.4) Peer requests for the content from the identified peers,
or receives the content from its parent node.</t>
</list></t>
<t>2) When a peer wants to share streaming content with others:<list>
<t>2.1) Peer sends information to the tracker about the swarms
it belongs to, plus streaming status and/or content
availability.</t>
</list></t>
</list></t>
<figure>
<artwork> +---------------------------------------------------------+
| +--------------------------------+ |
| | Tracker | |
| +--------------------------------+ |
| ^ | ^ |
| | | | |
| query | | peer list/ |streaming Status/ |
| | | Parent nodes |Content availability/ |
| | | |node capability |
| | | | |
| | V | |
| +-------------+ +------------+ |
| | Peer1 |<------->| Peer 2 | |
| +-------------+ content/+------------+ |
| join requests |
+---------------------------------------------------------+
Figure 8, A common P2P streaming process model
</artwork>
</figure>
<t>The functionality of Tracker and data transfer in Mesh-based
application and Tree-based is a little different. In the Mesh-based
applications, such as Joost and PPLive, Tracker maintains the lists of
peers storing chunks for a specific channel or streaming file. It
provides peer list for peers to download from, as well as upload to,
each other. In the Tree-based applications, such as PeerCast and
Canviva, Tracker directs new peers to find parent nodes and the data
flows from parent to child only.</t>
</section>
<section title="Security Considerations">
<t>This document does not consider security issues. It follows the
security consideration in [draft-zhang-ppsp-problem-statement].</t>
</section>
<section title="Acknowledgments">
<t>We would like to acknowledge Jiang xingfeng for providing good ideas
for this document.</t>
</section>
</middle>
<back>
<references title="Informative References ">
<reference anchor="PPLive">
<front>
<title>www.pplive.com</title>
<author></author>
<date />
</front>
</reference>
<reference anchor="PPStream">
<front>
<title>www.ppstream.com</title>
<author></author>
<date />
</front>
</reference>
<reference anchor="CNN">
<front>
<title>www.cnn.com</title>
<author></author>
<date />
</front>
</reference>
<reference anchor="OctoshapeWeb">
<front>
<title>www.octoshape.com</title>
<author></author>
<date />
</front>
</reference>
<reference anchor="Joost-Experiment">
<front>
<title>An Experimental Analysis of Joost Peer-to-Peer VoD
Service</title>
<author fullname="Jun Lei, Lei shi and Xiaoming Fu"
initials="Jun, et al." surname="Lei"></author>
<date />
</front>
</reference>
<reference anchor="Sigcomm_P2P_Streaming">
<front>
<title>Challenges, Design and Analysis of a Large-scale P2P-VoD
System</title>
<author fullname="Yan Huang et al," initials="Yan, et al."
surname="Huang"></author>
<date day="" year="2008" />
</front>
</reference>
<reference anchor="Octoshape">
<front>
<title>Introducing Octoshape-a new technology for large-scale
streaming over the Internet</title>
<author fullname="Stephen Alstrup, Theis Rauhe"
initials="Stephen, et al." surname="Alstrup"></author>
<date />
</front>
</reference>
<reference anchor="Zattoo">
<front>
<title>http: //zattoo.com/</title>
<author></author>
<date />
</front>
</reference>
<reference anchor="Conviva">
<front>
<title>http://www.rinera.com/</title>
<author></author>
<date />
</front>
</reference>
<reference anchor="ESM04">
<front>
<title>End System Multicast,
http://www.cs.cmu.edu/~hzhang/Talks/ESMPrinceton.pdf</title>
<author fullname="Hui Zhang" initials="Hui" surname="Zhang"></author>
<date month="May" />
</front>
</reference>
<reference anchor="Survey">
<front>
<title>A survey on peer-to-peer video streaming systems</title>
<author fullname="Yong Liu et al" initials="Yong, et al."
surname="Liu"></author>
<date year="2008" />
</front>
</reference>
<reference anchor="draft-zhang-alto-traceroute-00">
<front>
<title>www.ietf.org/internet-draft/draft-zhang-alto-traceroute-00.txt</title>
<author></author>
<date />
</front>
</reference>
<reference anchor="P2PStreamingSurvey">
<front>
<title>Survey of P2P Streaming</title>
<author fullname="Zong, N. and X. Jiang, " initials="Ning, et al."
surname="Zong"></author>
<date month="Nov." year="2008" />
</front>
</reference>
<reference anchor="P2PIPTV_measuring">
<front>
<title>Measuring P2P IPTV Systems</title>
<author fullname="Thomas Silverston, Olivier Fourmaux"
initials="Thomas, et al." surname="Silverston"></author>
<date />
</front>
</reference>
<reference anchor="Challenge">
<front>
<title>Peer-to-Peer Live Video Streaming on the Internet: Issues,
Existing Approaches, and Challenges</title>
<author fullname="Bo Li et al" initials="Bo, et al." surname="Li"></author>
<date month="June" year="2007" />
</front>
</reference>
<reference anchor="NewCoolstreaming">
<front>
<title>Inside the New Coolstreaming: Principles,Measurements and
Performance Implications</title>
<author fullname="Bo Li et al" initials="Bo, et al." surname="Li"></author>
<date month="Apr." year="2008" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:22:11 |