draft-ietf-ppsp-survey-08.txt   draft-ietf-ppsp-survey-09.txt 
PPSP Y. Gu PPSP Y. Gu
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Informational N. Zong, Ed. Intended status: Informational N. Zong, Ed.
Expires: October 5, 2014 Huawei Expires: April 30, 2015 Huawei
Y. Zhang Y. Zhang
Coolpad Coolpad
China Mobile China Mobile
F. Piccolo F. Piccolo
Cisco Cisco
S. Duan S. Duan
CATR CATR
April 3, 2014 October 27, 2014
Survey of P2P Streaming Applications Survey of P2P Streaming Applications
draft-ietf-ppsp-survey-08 draft-ietf-ppsp-survey-09
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. The main Peer (P2P) streaming applications on the Internet. The main
selection criteria have been popularity and availability of selection criteria have been popularity and availability of
information on operation details at writing time. In doing this, information on operation details at writing time. In doing this,
selected applications are not reviewed as a whole, but they are selected applications are not reviewed as a whole, but they are
reviewed with main focus on the signaling and control protocol used reviewed with main focus on the signaling and control protocol used
to establish and maintain overlay connections among peers and to to establish and maintain overlay connections among peers and to
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 October 5, 2014. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 3, line 48 skipping to change at page 3, line 48
| +-------------+ +------------+ | | +-------------+ +------------+ |
| Peer Protocol | | 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 the system dynamically 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 peers. According to this model, it is possible to distinguish
between two different control/signaling protocols: between two different control/signaling protocols:
-the "tracker protocol" that regulates the interaction between -the "tracker protocol" for the interaction between trackers and
trackers and peer; peer;
-the "peer protocol" that regulates the interaction between peers. -the "peer protocol" for the interaction between peers.
Hence, whenever possible, we always try to identify 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 3 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 4 presents some of the most tree-based and hybrid. Then, Section 4 presents some of the most
skipping to change at page 4, line 41 skipping to change at page 4, line 41
live streaming, video-on-demand (VOD), peer, tracker, swarm, which live streaming, video-on-demand (VOD), peer, tracker, swarm, which
will be extensively used throughout the document. will be extensively used throughout the document.
In addition, reader can refer to this section for the following In addition, reader can refer to this section for the following
concepts. concepts.
CHANNEL: A CHANNEL denotes a TV channel from which live streaming CHANNEL: A CHANNEL denotes a TV channel from which live streaming
content is transmitted in a P2P streaming application. content is transmitted in a P2P streaming application.
PEER PROTOCOL: PEER PROTOCOL denotes the control and signaling PEER PROTOCOL: PEER PROTOCOL denotes the control and signaling
protocol that regulates interaction among peers. protocol for the interaction among peers.
PULL: PULL denotes the transmission of multimedia content that is PULL: PULL denotes the transmission of multimedia content that is
initiated by receiving peers. initiated by receiving peers.
PUSH: PUSH denotes the transmission of multimedia content that is not PUSH: PUSH denotes the transmission of multimedia content that is not
initiated by receiving peers. initiated by receiving peers.
TRACKER PROTOCOL: TRACKER PROTOCOL denotes the control and signaling TRACKER PROTOCOL: TRACKER PROTOCOL denotes the control and signaling
protocol that regulates interaction among peers and trackers. protocol for the 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 of overlay connections among peers, it is Depending on the topology of overlay connections among peers, it is
possible to distinguish among the following general types of P2P possible to distinguish among the following general types of P2P
streaming applications: streaming applications:
-mesh-based: peers are organized in a randomly connected overlay -mesh-based: peers are organized in a randomly connected overlay
network, and multimedia content delivery is pull-based. This is network, and multimedia content delivery is pull-based. This is
skipping to change at page 6, line 15 skipping to change at page 6, line 15
different network paths, and this may imply for end users playback different network paths, and this may imply for end users playback
quality degradation ranging from low bit rates to long start-up 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.
4.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 live 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.
Figure 2 depicts the architecture of the Octoshape system. Figure 2 depicts the architecture of the Octoshape system.
+------------+ +--------+ +------------+ +--------+
| Peer 1 |---| Peer 2 | | Peer 1 |---| Peer 2 |
+------------+ +--------+ +------------+ +--------+
| \ / | | \ / |
| \ / | | \ / |
| \ | | \ |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
+--------------+ +-------------+ +--------------+ +-------------+
| Peer 4 |----| Peer3 | | Peer 4 |----| Peer 3 |
+--------------+ +-------------+ +--------------+ +-------------+
***************************************** *****************************************
| |
| |
+---------------+ +---------------+
| Content Server| | Content Server|
+---------------+ +---------------+
Figure 2, Architecture of Octoshape system Figure 2, Architecture of Octoshape system
skipping to change at page 7, line 46 skipping to change at page 7, line 46
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.
4.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 served 50 millions visitors during the Beijing 2008 Olympics
Beijing 2008 Olympics, and the dedicated Olympics channel attracted opening ceremony, and the dedicated Olympics channel attracted 221
221 millions of views in two weeks. millions of viewers 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:
-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;
-peer, also called node or client, that is PPLive entity -peer, also called node or client, that is PPLive entity
skipping to change at page 9, line 7 skipping to change at page 9, line 7
+------------------------------+ +------------------------------+
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 implemented 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 peer sends out probes to establish active peer connections, a PPLive peer sends out probes to establish active peer connections,
and some of those peers may return also their own list of active and some of those peers may return also their own list of active
peers to help the new peer discover more peers in the initial phase. peers to help the new peer discover more peers in the initial phase.
Chunk 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.
Since the protocols and algorithm of PPLIVE are proprietary, most of Since the protocols and algorithm of PPLive are proprietary, most of
known details have been derived from measurement studies. known details have been derived from measurement studies.
Specifically, it seems that: Specifically, it seems that:
-number of peers from which a PPLive node downloads live TV chunks -number of peers from which a PPLive node downloads live TV chunks
from is constant and relatively low, and the top-ten peers 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];
-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
skipping to change at page 10, line 35 skipping to change at page 10, line 35
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 that Authentication server is the first point of contact for a peer that
joins the system, and it authenticates Zattoo users. Then, a user joins the system, and it authenticates Zattoo users. Then, a user
contacts the Rendezvous server and specifies the TV channel of contacts the Rendezvous server and specifies the TV channel of
interest. The rendezvous server returns a list of Zattoo peers that interest. The rendezvous server returns a list of Zattoo peers that
have already joined the requested channel. Hence, rendezvous server have already joined the requested channel. Hence, rendezvous server
plays the role of tracker. At this point the direct interaction plays the role of tracker. At this point the direct interaction
between peers starts and it is regulated by the peer protocol. between peers starts using 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 peers besides the ones indicated by user, if needed, can contact new peers besides the ones indicated by
the rendezvous server. In selecting which peers to establish the rendezvous server. In selecting which peers to establish
connections with, a peer adopts the criterion of topological connections with, a peer adopts the criterion of topological
skipping to change at page 11, line 22 skipping to change at page 11, line 22
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 (a mechanism very similar to the one of TCP congestion window window (a mechanism very similar to the one of TCP congestion window
(double increase or linear increase depending on whether the estimate (double increase or linear increase depending on whether the estimate
is below or above a given threshold). is below or above a given threshold).
As it can be seen also in Figure 4, there exist two classes of Zattoo Figure 4 also shows that there exist two classes of Zattoo nodes:
nodes: simple peers, whose behavior has already been presented, and simple peers, whose behavior has already been presented, and repeater
repeater nodes, that implement the same peer protocol as simple peers nodes, that implement the same peer protocol as simple peers and in
and in addition are high-bandwidth peers and are able to forward any addition are high-bandwidth peers and are able to forward any sub-
sub-stream. In such a way repeater nodes serve as bandwidth stream. In such a way repeater nodes serve as bandwidth multiplier.
multiplier.
4.4. PPStream 4.4. PPStream
PPStream [PPStream] is a very popular P2P streaming software in China PPStream [PPStream] is a very popular P2P streaming software in 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
skipping to change at page 12, line 7 skipping to change at page 12, line 7
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 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.
4.5. Tribler 4.5. Tribler
Tribler [tribler] is a BitTorrent client that was able to go very Tribler [Tribler] is a BitTorrent [Bittorrent] client that was able
much beyond BitTorrent model also thanks to the support for video to go very much beyond BitTorrent model also thanks to the support
streaming. Initially developed by a team of researchers at Delft for video streaming. Initially developed by a team of researchers at
University of Technology, Tribler was able to both i) attract Delft 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
interact with each other only when they actually upload/download interact with each other only when they actually upload/download
chunks to/from each other, there is no tracker server in Tribler and, chunks to/from each other, there is no tracker server in Tribler and,
as a consequence, there is no need of tracker protocol. as a consequence, there is no need of tracker protocol.
This is illustrated also in Figure 5, which depicts the high level This is illustrated also in Figure 5, which depicts the high level
skipping to change at page 14, line 26 skipping to change at page 14, line 26
description provided for video on demand scenario. description provided for video on demand scenario.
4.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 Content Delivery Network (CDN) and P2P architecture for QQLive adopts Content Delivery Network (CDN) [CDN] and P2P
video distribution and is different from other popular P2P streaming architecture for video distribution and is different from other
applications. QQLive provides video by source servers and CDN, and popular P2P streaming applications. QQLive provides video by source
the video content can be push to every region by CDN throughout servers and CDN, and the video content can be push to every region by
China. In each region, QQLive adopts P2P technology for video CDN throughout China. In each region, QQLive adopts P2P technology
content distribution. 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 takes 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 [RFC5389] and Tracker Server. Stun Server is responsible
traversing. Tracker Server is responsible for providing content for NAT traversing. Tracker Server is responsible for providing
address information. There are a group of these two Servers for content address information. There are a group of these two Servers
providing services. There is no Super Peer in QQLive. for 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.
-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.
-Play stage includes interactions between peers and peers or peers -Play stage includes interactions between peers and peers or peers
skipping to change at page 19, line 5 skipping to change at page 19, line 5
assigns them with a limited lifetime ticket. Then, a user presents assigns them with a limited lifetime ticket. Then, a user presents
the tickets received by the authentication server to the rendezvous the tickets received by the authentication server to the rendezvous
server. Provided that the presented ticket is valid, the rendezvous server. Provided that the presented ticket is valid, the rendezvous
server returns a list of Zattoo peers that have already joined the server returns a list of Zattoo peers that have already joined the
requested channel and a signed channel ticket. requested channel and a signed channel ticket.
In Tribler authentication of peers is based on secure, permanent peer In Tribler authentication of peers is based on secure, permanent peer
identifiers called PermIDs. PermID maps to a single IP address and identifiers called PermIDs. PermID maps to a single IP address and
port number and is initially used to identify users. The idea is to port number and is initially used to identify users. The idea is to
have each Tribler user assigned with a public/private keypair based have each Tribler user assigned with a public/private keypair based
on Elliptic Curve Cryptography, where public key acts as the PermID on Elliptic Curve Cryptography (ECC), where public key acts as the
for the user. The rationale behind the choice of Elliptic Curve PermID for the user. Users distribute their PermID to their friends
Cryptography is that it provides stronger protection using small keys out-of-band to establish trusted friend relationships. When two
than e.g. RSA-based algorithms and it thus allows caching of large peers connect as part of a download, they authenticate each other
numbers of (PermID,IP) pairs. Users distribute their PermID to their using the standard ISO/IEC 9798-3 [ISO/IEC 9798-3] challenge/response
friends out-of-band to establish trusted friend relationships. When identification protocol. If the peer is successfully authenticated
two peers connect as part of a download, they authenticate each other but not a friend of the user (i.e., does not appear in the list of
using the standard ISO/IEC 9798-3 challenge/response identification friends' PermIDs), the Tribler client will allow it to request non-
protocol. If the peer is successfully authenticated but not a friend privileged operations, such as exchanging file preferences. If the
of the user (i.e., does not appear in the list of friends' PermIDs), peer is a friend, it may request privileged operations such as
the Tribler client will allow it to request non-privileged coordinating a friends-assisted download. Moreover, Tribler provides
operations, such as exchanging file preferences. If the peer is a security at streamed content level too. In the video on demand
friend, it may request privileged operations such as coordinating a scenario torrent files include a hash for each chunk in order to
friends-assisted download. Moreover, Tribler provides security at prevent malicious attackers from corrupting data. In live streaming
streamed content level too. In the video on demand scenario torrent scenario torrent files include the public key of the stream source.
files include a hash for each chunk in order to prevent malicious Each chunk is then assigned with absolute sequence number and
attackers from corrupting data. In live streaming scenario torrent timestamp and signed by source public key. Such a mechanism allows
files include the public key of the stream source. Each chunk is Tribler peers to use the public key included in torrent file and
then assigned with absolute sequence number and timestamp and signed verify the integrity of each chunk.
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 In QQLive both tracker and peer protocol are fully private and
encrypt the whole message. The tracker protocol uses UDP and the encrypt the whole message. The tracker protocol uses UDP and the
port for the tracker server is fixed. For the streamed content, if 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 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 port 80 and no encryption. If the client gets the streaming from
other peers, the client use UDP to transfer the encrypted media other peers, the client use UDP to transfer the encrypted media
streaming and not RTP/RTCP. streaming and not RTP/RTCP.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 20, line 39 skipping to change at page 20, line 35
[CNSR] Li, Ruixuan, et al., "Measurement Study on PPLive Based on [CNSR] Li, Ruixuan, et al., "Measurement Study on PPLive Based on
Channel Popularity", May 2011. Channel Popularity", May 2011.
[Zattoo] Zattoo web site, http://www.zattoo.com [Zattoo] Zattoo web site, http://www.zattoo.com
[IMC09] Chang, Hyunseok, et al., "Live streaming performance of the [IMC09] Chang, Hyunseok, et al., "Live streaming performance of the
Zattoo network", November 2009. Zattoo network", November 2009.
[PPStream] PPStream web site, http:// www.ppstream.com [PPStream] PPStream web site, http:// www.ppstream.com
[tribler] Tribler Protocol Specification, January 2009, on line [Tribler] Tribler Protocol Specification, January 2009, on line
available at http://svn.tribler.org/bt2-design/proto-spec-unified/ available at http://svn.tribler.org/bt2-design/proto-spec-
trunk/proto-spec-current.pdf unified/trunk/proto-spec-current.pdf
[Bittorrent] BitTorrent web site, http:// www.bittorrent.com
[QQLive] QQLive web site, http://v.qq.com [QQLive] QQLive web site, http://v.qq.com
[CDN] CDN wiki, http://en.wikipedia.org/wiki/Content_delivery_network
[RFC5389] RFC5389, "Session Traversal Utilities for NAT (STUN)".
[conviva] Conviva web site, http://www.conviva.com [conviva] Conviva web site, http://www.conviva.com
[ESM1] Chu, Yang-hua, et al., "A Case for End System Multicast", June [ESM1] Chu, Yang-hua, et al., "A Case for End System Multicast", June
2000. (http://esm.cs.cmu.edu/technology/papers/ 2000. (http://esm.cs.cmu.edu/technology/papers/
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.
static.usenix.org/events/usenix04/tech/general/full_papers/chu/ (http://static.usenix.org/events/usenix04/tech/general/full_papers/
chu.pdf) chu/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.
[ISO/IEC 9798-3] ISO web site, http://www.iso.org/iso/
catalogue_detail.htm?csnumber=29062
Authors' Addresses Authors' Addresses
Yingjie Gu Yingjie Gu
Unaffiliated Unaffiliated
Email: guyingjie@gmail.com Email: guyingjie@gmail.com
Ning Zong (editor) Ning Zong (editor)
Huawei Huawei
101 Software Avenue 101 Software Avenue
 End of changes. 25 change blocks. 
67 lines changed or deleted 72 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/