draft-ietf-ppsp-survey-05.txt   draft-ietf-ppsp-survey-06.txt 
PPSP Y. Gu PPSP Y. Gu
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track N. Zong, Ed. Intended status: Informational N. Zong, Ed.
Expires: January 13, 2014 Huawei Expires: July 12, 2014 Huawei
Y. Zhang Y. Zhang
Coolpad Coolpad
F. Lo Piccolo China Mobile
F. Piccolo
Cisco Cisco
S. Duan S. Duan
CATR CATR
July 12, 2013 January 8, 2014
Survey of P2P Streaming Applications Survey of P2P Streaming Applications
draft-ietf-ppsp-survey-05 draft-ietf-ppsp-survey-06
Abstract Abstract
This document presents a survey of some of the most popular Peer-to- This document presents a survey of some of the most popular Peer-to-
Peer (P2P) streaming applications on the Internet. Main selection Peer (P2P) streaming applications on the Internet. The main
criteria have been popularity and availability of information on selection criteria have been popularity and availability of
operation details at writing time. In doing this, selected information on operation details at writing time. In doing this,
applications are not reviewed as a whole, but they are reviewed with selected applications are not reviewed as a whole, but they are
main focus on the signaling and control protocol used to establish reviewed with main focus on the signaling and control protocol used
and maintain overlay connections among peers and to advertise and to establish and maintain overlay connections among peers and to
download streaming content. advertise and download streaming content.
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/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2014. This Internet-Draft will expire on July 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminologies and concepts . . . . . . . . . . . . . . . . . 4 2. Terminologies and concepts . . . . . . . . . . . . . . . . . 4
3. Classification of P2P Streaming Applications Based on Overlay 3. Classification of P2P Streaming Applications Based on Overlay
Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Mesh-based P2P Streaming Applications . . . . . . . . . . 5 4. Mesh-based P2P Streaming Applications . . . . . . . . . . . . 5
3.1.1. Octoshape . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Octoshape . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. PPLive . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. PPLive . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Zattoo . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Zattoo . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.4. PPStream . . . . . . . . . . . . . . . . . . . . . . 11 4.4. PPStream . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.5. Tribler . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Tribler . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.6. QQLive . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. QQLive . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Tree-based P2P streaming applications . . . . . . . . . . 15 5. Tree-based P2P Streaming Systems . . . . . . . . . . . . . . 15
3.2.1. End System Multicast (ESM) . . . . . . . . . . . . . 16 5.1. End System Multicast (ESM) . . . . . . . . . . . . . . . 15
3.3. Hybrid P2P streaming applications . . . . . . . . . . . . 18 6. Hybrid P2P streaming applications . . . . . . . . . . . . . . 17
3.3.1. New Coolstreaming . . . . . . . . . . . . . . . . . . 18 6.1. New Coolstreaming . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Informative References . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Informative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
An ever-increasing number of multimedia streaming systems have been An ever-increasing number of multimedia streaming systems have been
adopting Peer-to-Peer (P2P) paradigm to stream multimedia audio and adopting Peer-to-Peer (P2P) paradigm to stream multimedia audio and
video contents from a source to a large number of end users. This is video contents from a source to a large number of end users. This is
the reference scenario of this document, which presents a survey of the reference scenario of this document, which presents a survey of
some of the most popular P2P streaming applications available on the some of the most popular P2P streaming applications available on the
nowadays Internet. nowadays Internet.
The presented survey does not aim at being exhaustive. Reviewed The presented survey does not aim at being exhaustive. Reviewed
applications have indeed been selected mainly based on their applications have indeed been selected mainly based on their
popularity and on the information publicly available on P2P operation popularity and on the information publicly available on P2P operation
details at writing time. details at writing time. In addition, the provided descriptions may
sometimes appear inhomogeneous from the detail level point of view,
but this always depends on the amount of available information at
writing time.
In addition, the selected applications are not reviewed as a whole, In addition, the selected applications are not reviewed as a whole,
but they are reviewed with main focus on signaling and control but they are reviewed with main focus on signaling and control
protocols used to construct and maintain the overlay connections protocols used to construct and maintain the overlay connections
among peers and to advertise and download multimedia content. More among peers and to advertise and download multimedia content. More
precisely, we assume throughout the document the high level system precisely, we assume throughout the document the high level system
model reported in Figure 1. model reported in Figure 1.
+--------------------------------+ +---------------------------------------------------------+
| Tracker | | +--------------------------------+ |
| Information on multimedia | | | Tracker | |
| content and peer set | | | | |
+--------------------------------+ | | Information on multimedia | |
^ | ^ | | | content and peer set | |
| | | | | +--------------------------------+ |
| | Traker | | Traker | ^ | ^ | |
| | Protocol | | Protocol | | | | | |
| | | | | | | Tracker | | Tracker |
| V | V | | | Protocol | | Protocol |
+-------------+ +------------+ | | | | | |
| Peer 1 |<--------| Peer 2 | | | | | | |
| |-------->| | | | | | | |
+-------------+ +------------+ | | V | V |
Peer Protocol | +-------------+ +------------+ |
| | Peer 1 |<--------| Peer 2 | |
| | |-------->| | |
| +-------------+ +------------+ |
| Peer Protocol |
| |
+---------------------------------------------------------+
Figure 1, High level architecture of P2P streaming systems assumed as Figure 1, High level architecture of P2P streaming systems assumed as
reference model througout the document reference model througout the document
As Figure 1 shows, it is possible to identify in every P2P streaming As Figure 1 shows, it is possible to identify in every P2P streaming
system two main types of entity: peers and trackers. Peers represent system two main types of entity: peers and trackers. Peers represent
end users, which join dynamically the system to send and receive end users, which join dynamically the system to send and receive
streamed media content, whereas trackers represent well-known nodes, streamed media content, whereas trackers represent well-known nodes,
which are stably connected to the system and provide peers with which are stably connected to the system and provide peers with
metadata information about the streamed content and the set of active metadata information about the streamed content and the set of active
peers. According to this model, it is possible to distinguish among peers. According to this model, it is possible to distinguish
two different control/signaling protocols: between two different control/signaling protocols:
1) the "tracker protocol" that regulates the interaction between -the "tracker protocol" that regulates the interaction between
trackers and peer; trackers and peer;
2) the "peer protocol" that regulates the interaction between -the "peer protocol" that regulates the interaction between peers.
peers.
Hence, whenever possible, we always try to identity tracker and peer Hence, whenever possible, we always try to identify tracker and peer
protocols and we provide the corresponding details. protocols and we provide the corresponding details.
This document is organized as follows. Section 2 introduces This document is organized as follows. Section 2 introduces
terminology and concepts used throughout the current survey. Since terminology and concepts used throughout the current survey. Since
overlay topology built on connections among peers impacts some overlay topology built on connections among peers impacts some
aspects of tracker and peer protocols, Section 2 classifies P2P aspects of tracker and peer protocols, Section 3 classifies P2P
streaming applications according to the overlay topology: mesh-based, streaming applications according to the overlay topology: mesh-based,
tree-based and hybrid. Then, Section 3 presents some of the most tree-based and hybrid. Then, Section 4 presents some of the most
popular mesh-based P2P streaming applications: Octoshape, PPLive, popular mesh-based P2P streaming applications: Octoshape, PPLive,
Zattoo, PPStream, Tribler, QQLive. Likewise, Section 4 presents End Zattoo, PPStream, Tribler, QQLive. Likewise, Section 5 presents End
System Multicast as example of tree-based P2P streaming applications. System Multicast as example of tree-based P2P streaming applications,
Finally Section 5 presents New Coolstreaming as example of hybrid- whereas Section 6 presents New Coolstreaming as example of hybrid-
topology P2P streaming application. topology P2P streaming application. Finally, Section 7 provides some
security considerations.
2. Terminologies and concepts 2. Terminologies and concepts
Channel: TV channel from which live streaming content is transmitted Reader is referred to RFC 6972 [RFC6972] for concepts such as chunk,
in a P2P streaming application. live streaming, video-on-demand (VOD), peer, tracker, swarm, which
will be extensively used throughout the document..
Chunk: Basic unit that a streaming media is partitioned into for the
purposes of storage, scheduling, advertisement and exchange among
peers.
Live streaming: Application that allows users to receive almost in
real-time multimedia content related to on ongoing event and streamed
from a source. The lag between the play points at the receivers and
the ones at the streaming source has to be small.
Peer: P2P node that dynamically participates in a P2P streaming
system not only to receive streaming content but also to store and
upload streaming content to other participants.
Peer protocol: Control and signaling protocol that regulates
interaction among peers.
Pull: Transmission of multimedia content only if requested by In addition, reader can refer to this section for the following
receiving peers. concepts.
Push: Transmission of multimedia content without any request from CHANNEL: A CHANNEL denotes a TV channel from which live streaming
receiving peers. content is transmitted in a P2P streaming application.
Swarm: A group of peers sharing the same streaming content at a given PEER PROTOCOL: PEER PROTOCOL denotes the control and signaling
time. protocol that regulates interaction among peers.
Tracker: P2P node that stably participates in a P2P streaming system PULL: PULL denotes the transmission of multimedia content that is
to provide a directory service by maintaining information both on the initiated by receiving peers.
peer set and on the chunks each peer stores.
Tracker protocol: Control and signaling protocol that regulates PUSH: PUSH denotes the transmission of multimedia content that is not
interaction among peers and trackers. initiated by receiving peers.
Video-on-demand (VoD): Application that allows users to select and TRACKER PROTOCOL: TRACKER PROTOCOL denotes the control and signaling
watch video content on demand. protocol that regulates interaction among peers and trackers.
3. Classification of P2P Streaming Applications Based on Overlay 3. Classification of P2P Streaming Applications Based on Overlay
Topology Topology
Depending on the topology that can be associated with overlay Depending on the topology of overlay connections among peers, it is
connections among peers, it is possible to distinguish among the possible to distinguish among the following general types of P2P
following general types of P2P streaming applications: streaming applications:
1) tree-based: peers are organized to form a tree-shape overlay -mesh-based: peers are organized in a randomly connected overlay
network, and multimedia content delivery is pull-based. This is
the reason why these systems are also referred to as "data-
driven". Due to their unstructured nature, mesh-based P2P
streaming applications are very resilient with respect to peer
churn and guarantee high network resource utilization. On the
other side, the cost to maintain overlay topology may limit
performance in terms of delay, and pull-based data delivery calls
for large size buffers to store chunks;
-tree-based: peers are organized to form a tree-shape overlay
network rooted at the streaming source, and multimedia content network rooted at the streaming source, and multimedia content
delivery is push-based. Peers that forward data are called parent delivery is push-based. Peers that forward data are called parent
nodes, and peers that receive it are called children nodes. Due nodes, and peers that receive it are called children nodes. Due
to their structured nature, tree-based P2P streaming applications to their structured nature, tree-based P2P streaming applications
guarantee both topology maintenance at very low cost and good guarantee both topology maintenance at very low cost and good
performance in terms of scalability and delay. On the other side, delay performance. On the other side, they are not very resilient
they are not very resilient to peer churn, that may be very high to peer churn, that may be very high in a P2P environment;
in a P2P environment;
2) mesh-based: peers are organized in a randomly connected overlay
network, and multimedia content delivery is pull-based. This is
the reason why these systems are also referred to as "data-
driven". Due to their unstructured nature, mesh-based P2P
streaming application are very resilient with respect to peer
churn and guarantee higher network resource utilization than the
one associated with tree-based applications. On the other side,
the cost to maintain overlay topology may limit performance in
terms of delay, and pull-based data delivery calls for large size
buffers where to store chunks;
3) hybrid: this category includes all the P2P applications that -hybrid: this category includes all the P2P applications that
cannot be classified as simply mesh-based or tree-based and cannot be classified as simply mesh-based or tree-based and
present characteristics of both mesh-based and tree-based present characteristics of both mesh-based and tree-based
categories. categories.
3.1. Mesh-based P2P Streaming Applications 4. Mesh-based P2P Streaming Applications
In mesh-based P2P streaming application peers self-organize in a In mesh-based P2P streaming application peers self-organize in a
randomly connected overlay graph where each peer interacts with a randomly connected overlay graph where each peer interacts with a
limited subset of other peers (neighbors) and explicitly requests limited subset of other peers (neighbors) and explicitly requests
chunks it needs (pull-based or data-driven delivery). This type of chunks it needs (pull-based or data-driven delivery). This type of
content delivery may be associated with high overhead, not only content delivery may be associated with high overhead, not only
because peers formulate requests in order to download chunks they because peers formulate requests in order to download chunks they
need, but also because in some applications peers exchange need, but also because in some applications peers exchange chunk
information about chunks they own (in form of so called buffer-maps, availability information in form of buffer-maps (a sort of bit maps
a sort of bit maps with a bit "1" in correspondence of chunks stored with a bit "1" in correspondence of chunks stored in the local
in the local buffer). On the one side, the main advantage of this buffer). On the one side, the main advantage of this kind of
kind of applications lies in that a peer does not rely on a single applications lies in that a peer does not rely on a single peer for
peer for retrieving multimedia content. Hence, these applications retrieving multimedia content. Hence, these applications are very
are very resilient to peer churn. On the other side, overlay resilient to peer churn. On the other side, overlay connections are
connections are highly dynamic and not persistent (being driven by highly dynamic and not persistent (being driven by content
content availability), and this makes content distribution efficiency availability), and this makes content distribution efficiency
unpredictable. In fact, different chunks may be retrieved via unpredictable. In fact, different chunks may be retrieved via
different network paths, and this may turn at end users into playback different network paths, and this may imply for end users playback
quality degradation ranging from low bit rates to long startup quality degradation ranging from low bit rates to long start-up
delays, to frequent playback freezes. Moreover, peers have to delays, to frequent playback freezes. Moreover, peers have to
maintain large buffers to increase the probability of satisfying maintain large buffers to increase the probability of satisfying
chunk requests received by neighbors. chunk requests received by neighbors.
3.1.1. Octoshape 4.1. Octoshape
Octoshape [Octoshape] is a P2P plug-in that has been realized by the Octoshape [Octoshape] is a P2P plug-in that has been realized by the
homonym Danish company and has become popular for being used by CNN homonym Danish company and has become popular for being used by CNN
[CNN] to broadcast living streaming content. Octoshape helps indeed [CNN] to broadcast living streaming content. Octoshape helps indeed
CNN serve a peak of more than a million simultaneous viewers thanks CNN serve a peak of more than a million simultaneous viewers thanks
not only to the P2P content distribution paradigm, but also to not only to the P2P content distribution paradigm, but also to
several innovative delivery technologies such as loss resilient several innovative delivery technologies such as loss resilient
transport, adaptive bit rate, adaptive path optimization and adaptive transport, adaptive bit rate, adaptive path optimization and adaptive
proximity delivery. proximity delivery.
skipping to change at page 7, line 6 skipping to change at page 6, line 46
***************************************** *****************************************
| |
| |
+---------------+ +---------------+
| Content Server| | Content Server|
+---------------+ +---------------+
Figure 2, Architecture of Octoshape system Figure 2, Architecture of Octoshape system
As it can be seen from the picture, there are no trackers and As it can be seen from the picture, there are no trackers and
consequently no tracker protocol is necessary. consequently no tracker protocol is necessary. The content server
plays indeed the role of tracker and transmits the information on
peers that already joined the channel in form of metadata when
streaming the live content.
As regards the peer protocol, information on peers that already As regards the peer protocol, each peer maintains a sort of Address
joined the channel is transmitted in form of metadata when streaming Book with the information necessary to contact other peers who are
the live content. In such a way each peer maintains a sort of watching the same channel.
Address Book with the information necessary to contact other peers
who are watching the same channel.
Regarding data distribution strategy, in the Octoshape solution the Regarding the data distribution strategy, in the Octoshape solution
original stream is split into a number K of smaller equal-sized data the original stream is split into a number K of smaller equal-sized
streams, but a number N > K of unique data streams are actually data streams, but a number N > K of unique data streams are actually
constructed, in such a way that a peer receiving any K of the N constructed, in such a way that a peer receiving any K of the N
available data streams is able to play the original stream. For available data streams is able to play the original stream. For
instance, if the original live stream is a 400 kbit/sec signal, for instance, if the original live stream is a 400 kbit/sec signal, for
K=4 and N=12, 12 unique data streams are constructed, and a peer that K=4 and N=12, 12 unique data streams are constructed, and a peer that
downloads any 4 of the 12 data streams is able to play the live downloads any 4 of the 12 data streams is able to play the live
stream. In this way, each peer sends requests of data streams to stream. In this way, each peer sends requests of data streams to
some selected peers, and it receives positive/negative answers some selected peers, and it receives positive/negative answers
depending on availability of upload capacity at requested peers. In depending on availability of upload capacity at requested peers. In
case of negative answers, a peer continues sending requests until it case of negative answers, a peer continues sending requests until it
finds K peers willing to upload the minimum number of data streams finds K peers willing to upload the minimum number of data streams
skipping to change at page 7, line 46 skipping to change at page 7, line 41
ready to take over if one of the current senders leaves or gets ready to take over if one of the current senders leaves or gets
congested. congested.
Finally, in order to optimize bandwidth utilization, Octoshape Finally, in order to optimize bandwidth utilization, Octoshape
leverages peers within a network to minimize external bandwidth usage leverages peers within a network to minimize external bandwidth usage
and to select the most reliable and "closest" source to each viewer. and to select the most reliable and "closest" source to each viewer.
It also chooses the best matching available codecs and players, and It also chooses the best matching available codecs and players, and
it scales bit rate up and down according to the available Internet it scales bit rate up and down according to the available Internet
connection. connection.
3.1.2. PPLive 4.2. PPLive
PPLive [PPLive] was first developed in Huazhong University of Science PPLive [PPLive] was first developed in Huazhong University of Science
and Technology in 2004, and it is one of the earliest and most and Technology in 2004, and it is one of the earliest and most
popular P2P streaming software in China. To give an idea, PPLive popular P2P streaming software in China. To give an idea, PPLive
website reached 50 millions of visitors for the opening ceremony of website reached 50 millions of visitors for the opening ceremony of
Beijing 2008 Olympics, and the dedicated Olympics channel attracted Beijing 2008 Olympics, and the dedicated Olympics channel attracted
221 millions of views in two weeks. 221 millions of views in two weeks.
Even though PPLive was renamed to PPTV in 2010, we continue using the Even though PPLive was renamed to PPTV in 2010, we continue using the
old name PPLive throughout this document. old name PPLive throughout this document.
PPLive system includes the following main components: PPLive system includes the following main components:
1) video streaming server, that plays the role of source of video -video streaming server, that plays the role of source of video
content and copes with content coding issues; content and copes with content coding issues;
2) peer, also called node or client, that is PPLive entity -peer, also called node or client, that is PPLive entity
downloading video content from other peers and uploading video downloading video content from other peers and uploading video
content to other peers; content to other peers
3) channel server, that provides the list of available channels -channel server, that provides the list of available channels
(live TV or VoD content) to a PPLive, as soon as the peer joins (live TV or VoD content) to a PPLive peer, as soon as the peer
the system; joins the system;
4) tracker server, that provides a PPLive peer with the list of -tracker server, that provides a PPLive peer with the list of
online peers that are watching the same channel as the one the online peers that are watching the same channel as the one the
joining peer is interested in. joining peer is interested in.
Figure 3 illustrates the high level diagram of PPLive system. Figure 3 illustrates the high level diagram of PPLive system.
+------------+ +------------+ +------------+ +------------+
| Peer 2 |----| Peer 3 | | Peer 2 |----| Peer 3 |
+------------+ +------------+ +------------+ +------------+
| | | | | | | |
| | | |
| +--------------+ | | +--------------+ |
| | Peer 1 | | | | Peer 1 | |
| +--------------+ | | +--------------+ |
| | | | | |
| | |
| | |
+------------------------------+ +------------------------------+
| | | |
| +----------------------+ | | +----------------------+ |
| |Video Streaming Server| | | |Video Streaming Server| |
| +----------------------+ | | +----------------------+ |
| | Channel Server | | | | Channel Server | |
| +----------------------+ | | +----------------------+ |
| | Tracker Server | | | | Tracker Server | |
| +----------------------+ | | +----------------------+ |
| | | |
skipping to change at page 9, line 15 skipping to change at page 9, line 9
Figure 3, High level overview of PPLive system architecture Figure 3, High level overview of PPLive system architecture
As regards the tracker protocol, as soon as a PPLive peer joins the As regards the tracker protocol, as soon as a PPLive peer joins the
systems and selects the channel to watch, it retrieves from the systems and selects the channel to watch, it retrieves from the
tracker server a list of peers that are watching the same channel. tracker server a list of peers that are watching the same channel.
As regards the peer protocol, it controls both peer discovery and As regards the peer protocol, it controls both peer discovery and
chunk distribution process. More specifically, peer discovery is chunk distribution process. More specifically, peer discovery is
regulated by a kind of gossip-like mechanism. After retrieving the regulated by a kind of gossip-like mechanism. After retrieving the
list of active peers watching a specific channel from tracker server, list of active peers watching a specific channel from tracker server,
a PPLive sends out probes to establish active peer connections, and a PPLive peer sends out probes to establish active peer connections,
some of those peers may return also their own list of active peers to and some of those peers may return also their own list of active
help the new peer discover more peers in the initial phase. Chunk peers to help the new peer discover more peers in the initial phase.
distribution process is mainly based on buffer map exchange to Chunk distribution process is mainly based on buffer map exchange to
advertise the availability of cached chunks. In more detail, PPLive advertise the availability of cached chunks. In more detail, PPLive
software client exploits two local buffers to cache chunks: the software client exploits two local buffers to cache chunks: the
PPLive TV engine buffer and media player buffer. The main reason PPLive TV engine buffer and media player buffer. The main reason
behind the double buffer structure is to address the download rate behind the double buffer structure is to address the download rate
variations when downloading chunks from PPLive network. In fact, variations when downloading chunks from PPLive network. In fact,
received chunks are first buffered and reassembled into the PPLive TV received chunks are first buffered and reassembled into the PPLive TV
engine buffer; as soon as the number of consecutive chunks in PPLive engine buffer; as soon as the number of consecutive chunks in PPLive
TV engine buffer overcomes a predefined threshold, the media player TV engine buffer overcomes a predefined threshold, the media player
buffer downloads chunks from the PPLive TV engine buffer; finally, buffer downloads chunks from the PPLive TV engine buffer; finally,
when the media player buffer fills up to the required level, the when the media player buffer fills up to the required level, the
actual video playback starts. actual video playback starts.
Being the nature of PPLive protocols and algorithm proprietary, most -number of peers from which a PPLive node downloads live TV chunks
of known details have been derived from measurement studies. from is constant and relatively low, and the top-ten peers
Specifically, it seems that:
1) number of peers from which a PPLive node downloads live TV
chunks from is constant and relatively low, and the top-ten peers
contribute to a major part of the download traffic, as shown in contribute to a major part of the download traffic, as shown in
[P2PIPTVMEA]; [P2PIPTVMEA];
2) PPLive can provide satisfactory performance for popular live TV -PPLive can provide satisfactory performance for popular live TV
and VoD channels. For unpopular live TV channels, performance may and VoD channels. For unpopular live TV channels, performance may
severely degrade, whereas for unpopular VoD channels this problem severely degrade, whereas for unpopular VoD channels this problem
rarely happens, as it shown in [CNSR]. Authors of [CNSR] also rarely happens, as it shown in [CNSR]. Authors of [CNSR] also
demonstrate that the workload in most VoD channels is well demonstrate that the workload in most VoD channels is well
balanced, whereas for live TV channels the workload distribution balanced, whereas for live TV channels the workload distribution
is unbalanced, and a small number of peers provide most video is unbalanced, and a small number of peers provide most video
data. data.
3.1.3. Zattoo Since the protocols and algorithm of PPLIVE are proprietary, most of
known details have been derived from measurement studies.
Specifically, it seems that:
4.3. Zattoo
Zattoo [Zattoo] is P2P live streaming system that was launched in Zattoo [Zattoo] is P2P live streaming system that was launched in
Switzerland in 2006 in coincidence with the EUFA European Football Switzerland in 2006 in coincidence with the EUFA European Football
Championship and in few years was able to attract almost 10 million Championship and in few years was able to attract almost 10 million
registered users in several European countries. registered users in several European countries.
Figure 4 depicts the high level architecture of Zattoo system. The Figure 4 depicts the high level architecture of Zattoo system. The
main reference for the information provided in this document is main reference for the information provided in this document is
[IMC09]. [IMC09].
+-------------------------------------+ +-----------------------------------+
| ------------------------------- | +------+ | ------------------------------- | +------+
| | Broadcast Server | |---|Peer 1|---| | | Broadcast Server | |---|Peer 1|---|
| ------------------------------- | +------+ | | ------------------------------- | +------+ |
| | Authentication Server | | +--------------+ | | Authentication Server | | +-------------+
| ------------------------------- | | Repeater node| | ------------------------------- | |Repeater node|
| | Rendezvous Server | | +--------------+ | | Rendezvous Server | | +-------------+
| ------------------------------- | +------+ | | ------------------------------- | +------+ |
| | Bandwidth Estimation Server | |---|Peer 2|---| | | Bandwidth Estimation Server | |---|Peer 2|---|
| ------------------------------- | +------+ | ------------------------------- | +------+
| | Other Servers | | | | Other Servers | |
| ------------------------------- | | ------------------------------- |
+-------------------------------------+ +-----------------------------------+
Figure 4, High level overview of Zattoo system architecture Figure 4, High level overview of Zattoo system architecture
Broadcast server is in charge of capturing, encoding, encrypting and Broadcast server is in charge of capturing, encoding, encrypting and
sending the TV channel to the Zattoo network. A number N of logical sending the TV channel to the Zattoo network. A number N of logical
sub-streams is derived from the original stream, and packets of the sub-streams is derived from the original stream, and packets of the
same order in the sub-streams are grouped together into the so-called same order in the sub-streams are grouped together into the so-called
segments. Each segment is then coded via a Reed-Salomon error segments. Each segment is then coded via a Reed-Salomon error
correcting code in such a way that any number k < N of received correcting code in such a way that any number k < N of received
packets in the segment is enough to reconstruct the whole segment. packets in the segment is enough to reconstruct the whole segment.
Authentication server is the first point of contact for a peer the Authentication server is the first point of contact for a peer that
joins the system. It authenticates Zattoo users and assigns them joins the system, and it authenticates Zattoo users. Then, a user
with a limited lifetime ticket. Then, a user contacts the Rendezvous contacts the Rendezvous server and specifies the TV channel of
server and specifies the TV channel of interest. It also presents interest. The rendezvous server returns a list of Zattoo peers that
the tickets received by the authentication server. Provided that the have already joined the requested channel. Hence, rendezvous server
presented ticket is valid, the rendezvous server returns a list of plays the role of tracker. At this point the direct interaction
Zattoo peers that have already joined the requested channel and a between peers starts and it is regulated by the peer protocol.
signed channel ticket. Hence, rendezvous server plays the role of
tracker. At this point the direct interaction between peers starts
and it is regulated by the peer protocol.
A new Zattoo user contacts the peers returned by the rendezvous A new Zattoo user contacts the peers returned by the rendezvous
server in order to identify a set of neighboring peers covering the server in order to identify a set of neighboring peers covering the
full set of sub-streams in the TV channel. This process is denoted full set of sub-streams in the TV channel. This process is denoted
in Zattoo jargon as Peer Division Multiplexing (PDM). To ease the in Zattoo jargon as Peer Division Multiplexing (PDM). To ease the
identification of neighboring peers, each contacted peer provides identification of neighboring peers, each contacted peer provides
also the list of its own known peers, in such a way that a new Zattoo also the list of its own known peers, in such a way that a new Zattoo
user, if needed, can contact new more peers besides the ones user, if needed, can contact new peers besides the ones indicated by
indicated by the rendezvous server. In selecting which peers to the rendezvous server. In selecting which peers to establish
establish connections with, a peer adopts the criterion of connections with, a peer adopts the criterion of topological
topological closeness. The topological location of a peer is defined closeness. The topological location of a peer is defined in Zattoo
in Zattoo as (in order of preference) its subset number, its as (in order of preference) its subset number, its autonomous system
autonomous system number and its country code, and its provided to number and its country code, and it is provided to each peer by the
each peer by the authentication server. authentication server.
Zattoo peer protocol provides also a mechanism to make PDM process Zattoo peer protocol provides also a mechanism to make PDM process
adaptive with respect to bandwidth fluctuations. First of all, a adaptive with respect to bandwidth fluctuations. First of all, a
peer controls the admission of new connections based on the available peer controls the admission of new connections based on the available
uplink bandwidth. This is estimated i) at beginning with each peer uplink bandwidth. This is estimated i) at beginning with each peer
sending probe messages to the Bandwidth Estimation server, and ii) sending probe messages to the Bandwidth Estimation server, and ii)
while forwarding sub-streams to other peers based on the quality-of- while forwarding sub-streams to other peers based on the quality-of-
service feedback received by those peers. A quality-of-service service feedback received by those peers. A quality-of-service
feedback is sent from the receiver to the sender only when the feedback is sent from the receiver to the sender only when the
quality of the received sub-stream is below a given threshold. So if quality of the received sub-stream is below a given threshold. So if
a quality-of-service feedback is received, a Zattoo peer decrements a quality-of-service feedback is received, a Zattoo peer decrements
the estimation of available uplink bandwidth, and if this drops below the estimation of available uplink bandwidth, and if this drops below
the amount needed to supports the current connections, a proper the amount needed to supports the current connections, a proper
number of connections is closed. On the other side, if no quality- number of connections is closed. On the other side, if no quality-
of-service feedback is received for a given time interval, a Zattoo of-service feedback is received for a given time interval, a Zattoo
peer increments the estimation of available uplink bandwidth peer increments the estimation of available uplink bandwidth
according to a mechanism very similar to the one of TCP congestion according to a mechanism very similar to the one of TCP congestion
window (double increase or linear increase depending on whether the window (a mechanism very similar to the one of TCP congestion window
estimate is below or a given threshold). (double increase or linear increase depending on whether the estimate
is below or above a given threshold).
As it can be seen also in Figure 4, there exist two classes of Zattoo As it can be seen also in Figure 4, there exist two classes of Zattoo
nodes: simple peers, whose behavior has already been presented, and nodes: simple peers, whose behavior has already been presented, and
Repeater nodes, that serve as bandwidth multiplier, are able to repeater nodes, that implement the same peer protocol as simple peers
forward any sub-stream and implement the same peer protocol as simple and in addition are high-bandwidth peers and are able to forward any
peers. sub-stream. In such a way repeater nodes serve as bandwidth
multiplier.
3.1.4. PPStream 4.4. PPStream
PPStream [PPStream] is a very populare P2P streaming software in PPStream [PPStream] is a very popular P2P streaming software in China
China and in many other countries of East Asia. and in many other countries of East Asia.
The system architecture of PPStream is very similar to the one of The system architecture of PPStream is very similar to the one of
PPLive. When a PPStream peer joins the system, it retrieves the list PPLive. When a PPStream peer joins the system, it retrieves the list
of channels from the channel list server. After selecting the of channels from the channel list server. After selecting the
channel to watch, a PPStream peer retrieves from the peer list server channel to watch, a PPStream peer retrieves from the peer list server
the identifiers of peers that are watching the selected channel, and the identifiers of peers that are watching the selected channel, and
it establishes connections that are used first of all to exchange it establishes connections that are used first of all to exchange
buffer-maps. In more detail, a PPStream chunk is identified by the buffer-maps. In more detail, a PPStream chunk is identified by the
play time offset which is encoded by the streaming source and it is play time offset which is encoded by the streaming source and it is
subdivided into sub-chunks. So buffer-maps in PPStream carry the subdivided into sub-chunks. So buffer-maps in PPStream carry the
play time offset information and are strings of bits that indicate play time offset information and are strings of bits that indicate
the availability of sub-chunks. After receiving the buffer-maps from the availability of sub-chunks. After receiving the buffer-maps from
the connected peers, a PPStream peer selects peers to download sub- the connected peers, a PPStream peer selects peers to download sub-
chunks from according to a rate-based algorithm, which maximizes the chunks according to a rate-based algorithm, which maximizes the
utility of uplink and downlink bandwidth. utility of uplink and downlink bandwidth.
3.1.5. Tribler 4.5. Tribler
Tribler [tribler] is a BitTorrent client that was able to go very Tribler [tribler] is a BitTorrent client that was able to go very
much beyond BitTorrent model also thanks to the support for video much beyond BitTorrent model also thanks to the support for video
streaming. Initially developed by a team of researchers at Delft streaming. Initially developed by a team of researchers at Delft
University of Technology, Tribler was able to both i) attract University of Technology, Tribler was able to both i) attract
attention from other universities and media companies and ii) receive attention from other universities and media companies and ii) receive
European Union research funding (P2P-Next and QLectives projects). European Union research funding (P2P-Next and QLectives projects).
Differently from BitTorrent, where a tracker server centrally Differently from BitTorrent, where a tracker server centrally
coordinates peers in uploads/downloads of chunks and peers directly coordinates peers in uploads/downloads of chunks and peers directly
skipping to change at page 13, line 27 skipping to change at page 13, line 19
the peers with highest similarity. Thanks to this mechanism each the peers with highest similarity. Thanks to this mechanism each
peer maintains two lists of peers: i) a list of its top-N taste peer maintains two lists of peers: i) a list of its top-N taste
buddies along with their current preference lists, and ii) a list of buddies along with their current preference lists, and ii) a list of
random peers. So a peer alternatively selects a peer from one of the random peers. So a peer alternatively selects a peer from one of the
lists and sends it its preference list, taste-buddy list and a lists and sends it its preference list, taste-buddy list and a
selection of random peers. The goal behind the propagation of this selection of random peers. The goal behind the propagation of this
kind of information is the support for the remote search function, a kind of information is the support for the remote search function, a
completely decentralized search service that consists in querying completely decentralized search service that consists in querying
Preference Cache of taste buddies in order to find the torrent file Preference Cache of taste buddies in order to find the torrent file
associated with an interest file. If no torrent is found in this associated with an interest file. If no torrent is found in this
way, Tribler users may alternatively resort to web-based torrent way, Tribler users may alternatively resort to a web-based torrent
collector servers available for BitTorrent clients. collector server available for BitTorrent clients.
As already said, Tribler supports video streaming in two different Tribler supports video streaming in two different forms: video on
forms: video on demand and live streaming. demand and live streaming.
As regards video on demand, a peer first of all keeps informed its As regards video on demand, a peer first of all keeps informed its
neighbors about the chunks it has. Then, on the one side it applies neighbors about the chunks it has. Then, on the one side it applies
suitable chunk-picking policy in order to establish the order suitable chunk-picking policy in order to establish the order
according to which to request the chunks he wants to download. This according to which to request the chunks he wants to download. This
policy aims to assure that chunks come to the media player in order policy aims to assure that chunks come to the media player in order
and in the same time that overall chunk availability is maximized. and in the same time that overall chunk availability is maximized.
To this end, the chunk-picking policy differentiates among high, mid To this end, the chunk-picking policy differentiates among high, mid
and low priority chunks depending on their closeness with the and low priority chunks depending on their closeness with the
playback position. High priority chunks are requested first and in playback position. High priority chunks are requested first and in
skipping to change at page 14, line 9 skipping to change at page 13, line 48
first policy as well. On the other side, Tribler peers follow the first policy as well. On the other side, Tribler peers follow the
give-to-get policy in order to establish which peer neighbors are give-to-get policy in order to establish which peer neighbors are
allowed to request chunks (according to BitTorrent jargon to be allowed to request chunks (according to BitTorrent jargon to be
unchoked). In more detail, time is subdivided in periods and after unchoked). In more detail, time is subdivided in periods and after
each period Tribler peers first sort their neighbors according to the each period Tribler peers first sort their neighbors according to the
decreasing numbers of chunks they have forwarded to other peers, decreasing numbers of chunks they have forwarded to other peers,
counting only the chunks they originally received from them. In case counting only the chunks they originally received from them. In case
of tie, Tribler sorts their neighbors according to the decreasing of tie, Tribler sorts their neighbors according to the decreasing
total number of chunks they have forwarded to other peers. Since total number of chunks they have forwarded to other peers. Since
children could lie regarding the number of chunks forwarded to children could lie regarding the number of chunks forwarded to
others, Tribler peers do directly not ask their children, but their others, Tribler peers do not ask their children directly, but their
grandchildren. In this way, Tribler peer unchokes the three highest- grandchildren. In this way, Tribler peer unchokes the three highest-
ranked neighbours and, in order to saturate upload bandwidth and in ranked neighbours and, in order to saturate upload bandwidth and in
the same time not decrease the performance of individual connections, the same time not decrease the performance of individual connections,
it further unchokes a limited number of neighbors. Moreover, in it further unchokes a limited number of neighbors. Moreover, in
order to search for better neighbors, Tribler peers randomly select a order to search for better neighbors, Tribler peers randomly select a
new peer in the rest of the neighbours and optimistically unchoke it new peer in the rest of the neighbours and optimistically unchoke it
every two periods. every two periods.
As regards live streaming, differently from video on demand scenario, As regards live streaming, differently from video on demand scenario,
the number of chunks cannot be known in advance. As a consequence a the number of chunks cannot be known in advance. As a consequence a
sliding window of fixed width is used to identify chunks of interest: sliding window of fixed width is used to identify chunks of interest:
every chunk that falls out the sliding window is considered outdated, every chunk that falls out the sliding window is considered outdated,
is locally deleted and is considered as deleted by peer neighbors as is locally deleted and is considered as deleted by peer neighbors as
well. In this way, when a peer joins the network, it learns about well. In this way, when a peer joins the network, it learns about
chunks its neighbors possess and identify the most recent one. This chunks its neighbors possess and identify the most recent one. This
is assumed as beginning of the sliding window at the joining peer, is assumed as beginning of the sliding window at the joining peer,
which starts downloading and uploading chunks according to the which starts downloading and uploading chunks according to the
description provided for video on demand scenario. Finally, description provided for video on demand scenario.
differently from what happens for video on demand scenario, where
torrent files include a hash for each chunk in order to prevent
malicious attackers from corrupting data, torrent files in live
streaming scenario include the public key of the stream source. Each
chunk is then assigned with absolute sequence number and timestamp
and signed by source public key. Such a mechanism allows Tribler
peers to use the public key included in torrent file and verity the
integrity of each chunk.
3.1.6. QQLive 4.6. QQLive
QQLive [QQLive] is large-scale video broadcast software including QQLive [QQLive] is large-scale video broadcast software including
streaming media encoding, distribution and broadcasting. Its client streaming media encoding, distribution and broadcasting. Its client
can apply for web, desktop program or other environments and provides can apply for web, desktop program or other environments and provides
abundant interactive function in order to meet the watching abundant interactive function in order to meet the watching
requirements of different kinds of users. requirements of different kinds of users.
QQLive adopts CDN and P2P architecture for video distribution and is QQLive adopts Content Delivery Network (CDN) and P2P architecture for
different from other popular P2P streaming applications. QQLive video distribution and is different from other popular P2P streaming
provides video source by source servers and CDN and the video content applications. QQLive provides video by source servers and CDN, and
can be push to every region by CDN throughout China. In each region, the video content can be push to every region by CDN throughout
QQLive adopts P2P technology for video content distribution. China. In each region, QQLive adopts P2P technology for video
content distribution.
One of the main aims for QQLive is to use the simplest architecture One of the main aims for QQLive is to use the simplest architecture
to provide the best user experience. So QQLive take some servers to to provide the best user experience. So QQLive takes some servers to
implement P2P file distribution. There are two servers in QQLive: implement P2P file distribution. There are two servers in QQLive:
Stun Server and Tracker Server. Stun Server is responsible for NAT Stun Server and Tracker Server. Stun Server is responsible for NAT
traversing. Tracker Server is responsible for providing content traversing. Tracker Server is responsible for providing content
address information. There are a group of these two Servers for address information. There are a group of these two Servers for
providing services. There is no Super Peer in QQLive. providing services. There is no Super Peer in QQLive.
Working flow of QQLive includes startup stage and play stage. Working flow of QQLive includes startup stage and play stage.
1) Startup stage includes only interactions between peers and -Startup stage includes only interactions between peers and
Tracker servers. There is a built-in URL in QQLive client Tracker servers. There is a built-in URL in QQLive client
software. When the client startups and connects to the network, software. When the client startups and connects to the network,
the client gets the Tracker's address through DNS and tells the the client gets the Tracker's address through DNS and tells the
Tracker the information of its owned video contents. Tracker the information of its owned video contents.
2) play stage includes interactions between peers and peers or -Play stage includes interactions between peers and peers or peers
peers and CDN. Generally, the client will download the video and CDN. Generally, the client will download the video content
content from CDN during the first 30 seconds and then gets from CDN during the first 30 seconds and then gets contents from
contents from other peers. If unfortunately there is no peer other peers. If unfortunately there is no peer which owns the
which owns the content, the client will get the content from CDN content, the client will get the content from CDN again.
again.
As the client watches the video, the client will store the video to As the client watches the video, the client will store the video to
the hard disk. The default storage space is one Gbyte. If the the hard disk. The default storage space is one Gbyte. If the
storage space is full, the client will delete the oldest content. storage space is full, the client will delete the oldest content.
When the client do VCR operation, if the video content is stored in When the client does VCR operation, if the video content is stored in
hard disk, the client will not do interactions with other peers or hard disk, the client will not do interactions with other peers or
CDN. CDN. If there are messages or video content missing, the client will
take retransmission and the retransmission interval is decided by the
There are two main protocols in QQLive: tracker protocol and peer network condition. The QQLive does not take care of the strategy of
protocol. These two protocols are all full private and encrypt the transmission and chunk selection, which is simple and not similar
whole message. The tracker protocol uses UDP and the port for the with BT because of the CDN support.
tracker server is fixed. For the video streaming, if the client gets
the streaming from CDN, the client use the HTTP with port 80 and no
encryption; if the client gets the streaming from other peers, the
client use UDP to transfer the encrypted media streaming and not RTP/
RTCP.
If there are messages or video content missing, the client will take 5. Tree-based P2P Streaming Systems
retransmission and the retransmission interval is decided by the
network condition. The QQLive doesn't care the strategy of
transmission and chunk selection which is simple and not similar with
BT because of the CDN support.
3.2. Tree-based P2P streaming applications
In tree-based P2P streaming applications peers self-organize in a In tree-based P2P streaming applications peers self-organize in a
tree-shape overlay network, where peers do not ask for a specific tree-shape overlay network, where peers do not ask for a specific
chunk, but simply receive it from their so called "parent" node. chunk, but simply receive it from their so called "parent" node.
Such content delivery model is denoted as push-based. Receiving Such content delivery model is denoted as push-based. Receiving
peers are denoted as children, whereas sending nodes are denoted as peers are denoted as children, whereas sending nodes are denoted as
parents. Overhead to maintain overlay topology is usually lower for parents. Overhead to maintain overlay topology is usually lower for
tree-based streaming applications than for mesh-based streaming tree-based streaming applications than for mesh-based streaming
applications, whereas performance in terms of delay are usually applications, whereas performance in terms of delay is usually
higher. On the other side, the greatest drawback of this type of better. On the other side, the greatest drawback of this type of
application lies in that each node depends on one single node, its application lies in that each node depends on one single node, its
parent in overlay tree, to receive streamed content. Thus, tree- parent in overlay tree, to receive streamed content. Thus, tree-
based streaming applications suffer from peer churn phenomenon more based streaming applications suffer from peer churn phenomenon more
than mesh-based ones. than mesh-based ones.
3.2.1. End System Multicast (ESM) 5.1. End System Multicast (ESM)
Even though End System Multicast (ESM) project is ended by now and Even though End System Multicast (ESM) project is ended by now and
ESM infrastructure is not being currently implemented anywhere, we ESM infrastructure is not being currently implemented anywhere, we
decided to include it in this survey for a twofold reason. First of decided to include it in this survey for a twofold reason. First of
all, it was probably the first and most significant research work all, it was probably the first and most significant research work
proposing the possibility of implementing multicast functionality at proposing the possibility of implementing multicast functionality at
end hosts in a P2P way. Secondly, ESM research group at Carnegie end hosts in a P2P way. Secondly, ESM research group at Carnegie
Mellon University developed the first P2P live streaming system of Mellon University developed the first P2P live streaming system of
the world, and some members founded later Conviva [conviva] live the world, and some members founded later Conviva [conviva] live
platform. platform.
skipping to change at page 17, line 9 skipping to change at page 16, line 28
never exceeds a given bound, which reflects the bandwidth of the never exceeds a given bound, which reflects the bandwidth of the
peer's connection to the Internet. Each peer periodically emits a peer's connection to the Internet. Each peer periodically emits a
refresh message with monotonically increasing sequence number, which refresh message with monotonically increasing sequence number, which
is propagated across the mesh in such a way that each peer can is propagated across the mesh in such a way that each peer can
maintain a list of all the other peers in the system. When a peer maintain a list of all the other peers in the system. When a peer
leaves, either it notifies its neighbors and the information is leaves, either it notifies its neighbors and the information is
propagated across the mesh to all the participating peers, or peer propagated across the mesh to all the participating peers, or peer
neighbors detect the condition of abrupt departure and propagate it neighbors detect the condition of abrupt departure and propagate it
through the mesh. To improve mesh/tree quality, on the one side through the mesh. To improve mesh/tree quality, on the one side
peers constantly and randomly probe each other to add new links; on peers constantly and randomly probe each other to add new links; on
the other side, peers continually monitor existing links to drop the the other side, peers continually monitor existing links in order to
ones that are not perceived as good-quality links. This is done drop the ones that are not perceived as good-quality links. This is
thanks to the evaluation of a utility function and a cost function, done thanks to the evaluation of a utility function and a cost
which are conceived to guarantee that the shortest overlay delay function, which are conceived to guarantee that the shortest overlay
between any pair of peers is comparable to the unicast delay among delay between any pair of peers is comparable to the unicast delay
them. Regarding multicast tree construction phase, peers run a among them. Regarding multicast tree construction phase, peers run a
distance-vector protocol on top of the tree and use latency as distance-vector protocol on top of the tree and use latency as
routing metric. In this way, data delivery trees may be constructed routing metric. In this way, data delivery trees may be constructed
from the reverse shortest path between source and recipients. from the reverse shortest path between source and recipients.
The second and subsequent version of ESM architecture [ESM2] was The second and subsequent version of ESM architecture [ESM2] was
conceived for an operational large scale single-source Internet conceived for an operational large scale single-source Internet
broadcast system. As regards the mesh construction phase, a node broadcast system. As regards the mesh construction phase, a node
joins the system by contacting the source and retrieving a random joins the system by contacting the source and retrieving a random
list of already connected nodes. Information on active participating list of already connected nodes. Information on active participating
peers is maintained thanks to a gossip protocol: each peer peers is maintained thanks to a gossip protocol: each peer
skipping to change at page 18, line 5 skipping to change at page 17, line 24
stream is kept separated from video stream and multiple bit-rate stream is kept separated from video stream and multiple bit-rate
video streams are encoded at source and broadcast in parallel though video streams are encoded at source and broadcast in parallel though
the overlay tree. Audio is always prioritized over video streams, the overlay tree. Audio is always prioritized over video streams,
and lower quality video is always prioritized over high quality and lower quality video is always prioritized over high quality
video. In this way, system can dynamically select the most suitable video. In this way, system can dynamically select the most suitable
video stream according to receiver bandwidth and network congestion video stream according to receiver bandwidth and network congestion
level. Moreover, in order to take presence of hosts behind NAT/ level. Moreover, in order to take presence of hosts behind NAT/
firewalls, tree is structured in such a way that public hosts use firewalls, tree is structured in such a way that public hosts use
hosts behind NAT/firewalls as parents. hosts behind NAT/firewalls as parents.
3.3. Hybrid P2P streaming applications 6. Hybrid P2P streaming applications
This type of applications aims at integrating the main advantages of This type of applications aims at integrating the main advantages of
mesh-based and tree-based approaches. To this end, overlay topology mesh-based and tree-based approaches. To this end, overlay topology
is mixed mesh-tree, and content delivery model is push-pull. is mixed mesh-tree, and content delivery model is push-pull.
3.3.1. New Coolstreaming 6.1. New Coolstreaming
Coolstreaming, first released in summer 2004 with a mesh-based 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. Nevertheless, it suffers poor delay performance and live streaming. Nevertheless, it suffers poor delay performance and
high overhead associated with each video block transmission. In the high overhead associated with each video block transmission. In the
attempt of overcoming such a limitation, New Coolstreaming attempt of overcoming such a limitation, New Coolstreaming
[NEWCOOLStreaming] adopts a hybrid mesh-tree overlay structure and a [NEWCOOLStreaming] adopts a hybrid mesh-tree overlay structure and a
hybrid pull-push content delivery mechanism. hybrid pull-push content delivery mechanism.
Like in the old Coolstreaming, a newly joined node contacts a special Like in the old Coolstreaming, a newly joined node contacts a special
skipping to change at page 18, line 51 skipping to change at page 18, line 22
vector reports the sequence numbers of the last chunk received for a vector reports the sequence numbers of the last chunk received for a
given sub-stream. The second vector is used to explicitly request given sub-stream. The second vector is used to explicitly request
chunks from partner peers. In more details, the second vector has as chunks from partner peers. In more details, the second vector has as
many bits as sub-streams, and a peer receiving a bit "1" in many bits as sub-streams, and a peer receiving a bit "1" in
correspondence of a given sub-stream is being requested from the correspondence of a given sub-stream is being requested from the
sending peer to upload chunks belonging to that sub-streams. Since sending peer to upload chunks belonging to that sub-streams. Since
chunks are explicitly requested, data delivery may be regarded as chunks are explicitly requested, data delivery may be regarded as
pull-based. However, data delivery is push-based as well, since pull-based. However, data delivery is push-based as well, since
every time a node is requested to upload chunks, it uploads all every time a node is requested to upload chunks, it uploads all
chunks for that sub-stream starting from the one indicated in the chunks for that sub-stream starting from the one indicated in the
first vector of received buffer-map. first vector of received buffer-map. Hence, the overall overlay
topology is mesh-based, but it is also possible to identify as many
overlay trees as sub-streams.
In order to improve quality of mesh-tree overlay, each node In order to improve quality of mesh-tree overlay, each node
continuously monitors the quality of active connections in terms of continuously monitors the quality of active connections in terms of
mutual delay between sub-streams. If such quality drops below a mutual delay between sub-streams. If such quality drops below a
predefined threshold, a New Coolstreaming node selects a new partner predefined threshold, a New Coolstreaming node selects a new partner
among its partners. Parent re-selection is also applied in case of among its partners. Parent re-selection is also triggered for a peer
leaving of the previous parent. when its previous parent leaves.
4. Security Considerations 7. Security Considerations
This document does not raise security issues. Security in P2P streaming applications may be addressed at two
different levels: on the one side, at the control protocol level, on
the other side, at streamed multimedia content level.
5. Author List In PPLive and PPStream control protocol messages are sent over HTTP,
UDP and TCP mostly in plain text, and this can allow malicious users
to interfere with the normal operation of the system and can lead to
malicious attacks that can make key components of the system
ineffective.
In Zattoo authentication server authenticates Zattoo users and
assigns them with a limited lifetime ticket. Then, a user presents
the tickets received by the authentication server to the rendezvous
server. Provided that the presented ticket is valid, the rendezvous
server returns a list of Zattoo peers that have already joined the
requested channel and a signed channel ticket.
In Tribler authentication of peers is based on secure, permanent peer
identifiers called PermIDs. PermID maps to a single IP address and
port number and is initially used to identify users. The idea is to
have each Tribler user assigned with a public/private keypair based
on Elliptic Curve Cryptography, where public key acts as the PermID
for the user. The rationale behind the choice of Elliptic Curve
Cryptography is that it provides stronger protection using small keys
than e.g. RSA-based algorithms and it thus allows caching of large
numbers of (PermID,IP) pairs. Users distribute their PermID to their
friends out-of-band to establish trusted friend relationships. When
two peers connect as part of a download, they authenticate each other
using the standard ISO/IEC 9798-3 challenge/response identification
protocol. If the peer is successfully authenticated but not a friend
of the user (i.e., does not appear in the list of friends' PermIDs),
the Tribler client will allow it to request non-privileged
operations, such as exchanging file preferences. If the peer is a
friend, it may request privileged operations such as coordinating a
friends-assisted download. Moreover, Tribler provides security at
streamed content level too. In the video on demand scenario torrent
files include a hash for each chunk in order to prevent malicious
attackers from corrupting data. In live streaming scenario torrent
files include the public key of the stream source. Each chunk is
then assigned with absolute sequence number and timestamp and signed
by source public key. Such a mechanism allows Tribler peers to use
the public key included in torrent file and verify the integrity of
each chunk.
In QQLive both tracker and peer protocol are fully private and
encrypt the whole message. The tracker protocol uses UDP and the
port for the tracker server is fixed. For the streamed content, if
the client gets the streaming from CDN, the client use the HTTP with
port 80 and no encryption. If the client gets the streaming from
other peers, the client use UDP to transfer the encrypted media
streaming and not RTP/RTCP.
8. IANA Considerations
This document has no actions for IANA.
9. Author List
Other authors of this document are listed as below. Other authors of this document are listed as below.
Hui Zhang, NEC Labs America. Hui Zhang, NEC Labs America.
Jun Lei, University of Goettingen. Jun Lei, University of Goettingen.
Gonzalo Camarillo, Ericsson. Gonzalo Camarillo, Ericsson.
Yong Liu, Polytechnic University. Yong Liu, Polytechnic University.
Delfin Montuno, Huawei. Delfin Montuno, Huawei.
Lei Xie, Huawei. Lei Xie, Huawei.
6. Acknowledgments 10. 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 11. Informative References
[RFC6972] RFC 6972, "Problem Statement and Requirements of the Peer-
to-Peer Streaming Protocol (PPSP)".
[Octoshape] Alstrup, Stephen, et al., "Introducing Octoshape-a new [Octoshape] Alstrup, Stephen, et al., "Introducing Octoshape-a new
technology for large-scale streaming over the Internet". technology for large-scale streaming over the Internet".
[CNN] CNN web site, http://www.cnn.com [CNN] CNN web site, http://www.cnn.com
[PPLive] PPLive web site, http://www.pplive.com [PPLive] PPLive web site, http://www.pplive.com
[P2PIPTVMEA] Silverston, Thomas, et al., "Measuring P2P IPTV [P2PIPTVMEA] Silverston, Thomas, et al., "Measuring P2P IPTV
Systems", June 2007. Systems", June 2007.
skipping to change at page 20, line 30 skipping to change at page 21, line 13
Sigmetrics.CaseForESM.2000.pdf) Sigmetrics.CaseForESM.2000.pdf)
[ESM2] Chu, Yang-hua, et al., "Early Experience with an Internet [ESM2] Chu, Yang-hua, et al., "Early Experience with an Internet
Broadcast System Based on Overlay Multicast", June 2004. (http:// Broadcast System Based on Overlay Multicast", June 2004. (http://
static.usenix.org/events/usenix04/tech/general/full_papers/chu/ static.usenix.org/events/usenix04/tech/general/full_papers/chu/
chu.pdf) chu.pdf)
[NEWCOOLStreaming] Li, Bo, et al., "Inside the New Coolstreaming: [NEWCOOLStreaming] Li, Bo, et al., "Inside the New Coolstreaming:
Principles,Measurements and Performance Implications", April 2008. Principles,Measurements and Performance Implications", April 2008.
8. References
Authors' Addresses Authors' Addresses
Gu Yingjie Yingjie Gu
Unaffiliated Unaffiliated
Email: guyingjie@gmail.com Email: guyingjie@gmail.com
Zong Ning (editor) Ning Zong (editor)
Huawei Huawei
No.101 Software Avenue 101 Software Avenue
Nanjing 210012 Nanjing 210012
P.R.China China
Phone: +86-25-56624760 Phone: +86-25-56624760
Fax: +86-25-56624702 Fax: +86-25-56624702
Email: zongning@huawei.com Email: zongning@huawei.com
Zhang Yunfei
Yunfei Zhang
Coolpad Coolpad
China Mobile
Email: hishigh@gmail.com Email: hishigh@gmail.com
Francesca Lo Piccolo Francesca Lo Piccolo
Cisco Cisco
Via del Serafico 200 Via del Serafico 200
Rome 00142 Rome 00142
Italy Italy
Phone: +39-06-51645136 Phone: +39-06-51645136
Email: flopicco@cisco.com Email: flopicco@cisco.com
Shihui Duan
Duan Shihui
CATR CATR
No.52 HuaYuan BeiLu No.52 HuaYuan BeiLu
Beijing 100191 Beijing 100191
P.R.China P.R.China
Phone: +86-10-62300068 Phone: +86-10-62300068
Email: duanshihui@catr.cn Email: duanshihui@catr.cn
 End of changes. 96 change blocks. 
272 lines changed or deleted 309 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/