draft-ietf-ppsp-survey-06.txt   draft-ietf-ppsp-survey-07.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: July 12, 2014 Huawei Expires: October 5, 2014 Huawei
Y. Zhang Y. Zhang
Coolpad Coolpad
China Mobile China Mobile
F. Piccolo F. Piccolo
Cisco Cisco
S. Duan S. Duan
CATR CATR
January 8, 2014 April 3, 2014
Survey of P2P Streaming Applications Survey of P2P Streaming Applications
draft-ietf-ppsp-survey-06 draft-ietf-ppsp-survey-07
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 July 12, 2014. This Internet-Draft will expire on October 5, 2014.
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 4, line 32 skipping to change at page 4, line 32
Zattoo, PPStream, Tribler, QQLive. Likewise, Section 5 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,
whereas Section 6 presents New Coolstreaming as example of hybrid- whereas Section 6 presents New Coolstreaming as example of hybrid-
topology P2P streaming application. Finally, Section 7 provides some topology P2P streaming application. Finally, Section 7 provides some
security considerations. security considerations.
2. Terminologies and concepts 2. Terminologies and concepts
Reader is referred to RFC 6972 [RFC6972] for concepts such as chunk, Reader is referred to RFC 6972 [RFC6972] for concepts such as chunk,
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 that regulates interaction among peers.
skipping to change at page 9, line 25 skipping to change at page 9, line 25
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
known details have been derived from measurement studies.
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
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.
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 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].
skipping to change at page 13, line 46 skipping to change at page 13, line 46
first policy. Finally, when there are no more mid priority chunks to first policy. Finally, when there are no more mid priority chunks to
request, low priority chunks are requested according to a rarest- request, low priority chunks are requested according to a rarest-
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. In this
children could lie regarding the number of chunks forwarded to way, Tribler peer unchokes the three highest-ranked neighbours and,
others, Tribler peers do not ask their children directly, but their in order to saturate upload bandwidth and in the same time not
grandchildren. In this way, Tribler peer unchokes the three highest- decrease the performance of individual connections, it further
ranked neighbours and, in order to saturate upload bandwidth and in unchokes a limited number of neighbors. Moreover, in order to search
the same time not decrease the performance of individual connections, for better neighbors, Tribler peers randomly select a new peer in the
it further unchokes a limited number of neighbors. Moreover, in rest of the neighbours and optimistically unchoke it every two
order to search for better neighbors, Tribler peers randomly select a periods.
new peer in the rest of the neighbours and optimistically unchoke it
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
 End of changes. 9 change blocks. 
20 lines changed or deleted 18 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/