PPSP N. Zong, Ed.
Internet-Draft Huawei Technologies
Intended status: Standards Track Y. Zhang
Expires: April 25, 2010 China Mobile Communication
Corporation
V. Pascual
Tekelec
C. Williams
Consultant
October 22, 2009
P2P Streaming Protocol (PPSP) Requirements
draft-zong-ppsp-reqs-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2010.
Zong, et al. Expires April 25, 2010 [Page 1]
Internet-Draft PPSP Requirements October 2009
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The objective of the PPSP work is to standardize the key signaling
protocols that apply to tracker and peers in a Peer-to-Peer (P2P)
streaming system. These protocols are called PPSP. This document
enumerates the requirements for the PPSP, which should be considered
when designing PPSP.
Zong, et al. Expires April 25, 2010 [Page 2]
Internet-Draft PPSP Requirements October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of PPSP . . . . . . . . . . . . . . . . . . . . . . . 5
4. PPSP Requirements . . . . . . . . . . . . . . . . . . . . . . 6
4.1. PPSP Tracker Protocol Requirements . . . . . . . . . . . . 6
4.2. PPSP Peer Protocol Requirements . . . . . . . . . . . . . 7
4.3. PPSP Error Handling and Overload Protection
Requirements . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zong, et al. Expires April 25, 2010 [Page 3]
Internet-Draft PPSP Requirements October 2009
1. Introduction
Peer to Peer (P2P) computing has been successfully used in many
fields, from one to one communication like Voice over IP (VoIP) and
Instance Messaging (IM), to one to many communication like streaming,
file sharing and gaming. In the streaming area, the popularity of
P2P real-time and video on demand (VoD) streaming technology has been
demonstrated by PPlive [WWW.PPLive], PPStream [WWW.PPStream], UUSee
[WWW.UUSee], Pando [WWW.Pando] etc. Take PPLive for example, it has
over 5 million online users at the same time for real-time streaming.
Also some web2.0 streaming applications such as Youtube
[WWW.YouTube], Tudou [WWW.Tudou] are reported to use or are preparing
to use P2P engine to accelerate its downloading rate and cut down the
transmission cost. P2P streaming applications account for more and
more Internet traffic. According to statistics in a major Chinese
Internet Service Provider (ISP), the traffic generated by P2P
streaming applications exceeded 50% of the total backbone traffic
during peak time in 2008.[PPSPPS]
Given the increasing integration of P2P streaming into the global
content delivery infrastructure, the lack of an open, standard P2P
streaming protocol has become a major missing component in the
Internet protocol stack. Multiple similar but proprietary P2P
streaming protocols result in repetitious development efforts and
lock-in effects. More importantly, it leads to substantial
difficulties when integrating P2P streaming as a component of a
global content delivery infrastructure. For example, proprietary P2P
streaming protocols do not integrate well with infrastructure devices
such as caches and other edge devices.[PPSPPS]
The objective of the PPSP work is to standardize the key signaling
protocols that apply to tracker and peers in a P2P streaming system.
These protocols are called PPSP. PPSP will serve as an enabling
technology, building on the development experiences of existing P2P
streaming systems. Its design will allow it to integrate with IETF
efforts on distributed resource location, traffic localization, and
streaming control mechanisms. It allows effective integration with
edge infrastructures such as cache and mobile edge equipment.[PPSPPS]
This document enumerates the requirements for the PPSP, which should
be considered when designing PPSP.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and
Zong, et al. Expires April 25, 2010 [Page 4]
Internet-Draft PPSP Requirements October 2009
indicate requirement levels for compliant implementations.
This document uses the terms defined in [PPSPPS], including:
Chunk: A chunk is a basic unit of partitioned streaming, which is
used by a peer for the purpose of storage, advertisement and exchange
among peers.
Live streaming: The scenario where all clients receive streaming
content for the same ongoing event. The lags between the play points
of the clients and that of the streaming source are small.
Peer/PPSP peer: A peer/PPSP peer refers to a participant in a P2P
streaming system. The participant not only receives streaming
content, but also stores and uploads streaming content to other
participants.
PPSP: PPSP refer to the key signaling protocols among various P2P
streaming system components including the tracker and peer. PPSP are
a part of P2P streaming protocols.
Swarm: A swarm refers to a group of clients (i.e. peers) sharing the
same content (e.g. video/audio program, digital file, etc) at a given
time.
Tracker/PPSP tracker: A tracker/PPSP tracker refers to a directory
service which maintains lists of peers/PPSP peers storing chunks for
a specific channel or streaming file and answers queries from peers/
PPSP peers for peer lists.
Video-on-demand (VoD): The scenario where different clients watch
different parts of the media recorded and stored during past events.
3. Overview of PPSP
As described in [PPSPPS], the following components are considered in
the scope of PPSP:
1) Tracker communication. Tracker communication is a component that
enables each peer to get peer list from the tracker and/or provide
content availability to the tracker.
2) Peer communication. Peer communication is a component that
enables each peer to exchange content availability and request other
peers for content.
3) Report. Report is a component that enables peers to report
Zong, et al. Expires April 25, 2010 [Page 5]
Internet-Draft PPSP Requirements October 2009
streaming status to the tracker. The information may include peer
inbound/outbound traffic, amount of neighbor peers, peer health
degree and other streaming parameters.
Therefore, PPSP includes the PPSP tracker protocol - a signaling
protocol between PPSP trackers and PPSP peers, and the PPSP peer
protocol - a signaling protocol among PPSP peers.
PPSP tracker protocol will define:
1) Standard format/encoding of information between PPSP peers and
PPSP trackers, such as peer list, content availability, streaming
status including online time, link status, node capability and other
streaming parameters.
2) Standard messages between PPSP peers and PPSP trackers defining
how PPSP peers report streaming status and request to PPSP trackers,
as well as how PPSP trackers reply to the requests.
PPSP peer protocol will define:
1) Standard format/encoding of information among PPSP peers, such as
chunk description.
2) Standard messages among PPSP peers defining how PPSP peers
advertise chunk availability to each other, as well as the signaling
for requesting the chunks among PPSP peers.
This document itemizes requirements for the following aspects of
PPSP:
1) General functionalities of PPSP tracker protocol and basic types
of information communicated by PPSP tracker protocol.
2) General functionalities of PPSP peer protocol and basic types of
information communicated by PPSP peer protocol.
3) Error handling and overload protection requirements.
4) Security requirements.
4. PPSP Requirements
4.1. PPSP Tracker Protocol Requirements
PPSP.TP.REQ-1: PPSP tracker protocol MUST be able to carry peer list
information, such that each peer can get the list of peers which
Zong, et al. Expires April 25, 2010 [Page 6]
Internet-Draft PPSP Requirements October 2009
could provide the content.
PPSP.TP.REQ-2: PPSP tracker protocol MUST be able to carry swarm ID
(e.g. channel ID, streaming file ID).
The swarm ID can be used in two cases: 1) a peer requests the tracker
for the peer list indexed by a swarm ID; 2) a peer tells the tracker
about the swarms it belongs to.
PPSP.TP.REQ-3: PPSP tracker protocol MAY carry content availability
of the peers.
In some cases tracker may maintain the information of which pieces of
content reside in which peers, such that the tracker can assign the
appropriate peers for the requesting peer.
For example, a common expression of content availability is called
buffer map, indicating which chunks a peer currently has buffered and
can share with other peers. The buffer map can include the offset
(the ID of the first chunk stored by the peer), the length of the
buffer map, and a string of zeroes and ones indicating which chunks
are available (starting with the chunk designated by the offset).
<------- Buffer Map Length ------------->
+---+---+---+---+---+---+---+---+---+---+
<---------->| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 |
offset +---+---+---+---+---+---+---+---+---+---+
|-------------------------------------------------------------------->
Content Length
Figure 1: Buffer Map
PPSP.TP.REQ-4: PPSP tracker protocol MAY carry streaming status of
the peers. Streaming status of the peer include online time, link
status, peer capability and other streaming parameters of the peer.
Therefore, the tracker is able to select better candidate peers for
streaming based on the streaming status of the peers.
PPSP.TP.REQ-5: PPSP tracker protocol MAY be able to carry the service
status of the tracker, e.g. work load, capacity, etc.
4.2. PPSP Peer Protocol Requirements
PPSP.PP.REQ-1: PPSP peer protocol MUST be able to carry content
availability of the peers.
In order to share content among peers, peers must be able to tell
each other which pieces of content reside in which peers. After a
Zong, et al. Expires April 25, 2010 [Page 7]
Internet-Draft PPSP Requirements October 2009
peer receives content availability from other peers, the peer can
request content with other peers.
PPSP.PP.REQ-2: PPSP peer protocol May exchange additional peer list
in the communication after the first hand-shake between peers.
Note that tracker may only return an initial list of peers to the
requesting peer. A peer may need additional peers to connect with
and share content. Therefore, it is allowed that the peer
communicates with the peers in the current peer list to obtain
additional peer lists with which it aggregates the current peer list.
PPSP.PP.REQ-3: PPSP peer protocol May carry streaming status of the
peers. Streaming status information should be related to the content
delivery, including online time, link status, peer capability and
other streaming parameters of the peer. With this information, a
peer can select more appropriate peers for content sharing based on
some content sharing strategies and/or application requirements.
4.3. PPSP Error Handling and Overload Protection Requirements
PPSP.ERR.REQ-1: A peer MUST be able to respond with error information
to the peers sending PPSP messages, when some information (e.g. peer
list, chunk expression) cannot be understood in the message.
Local Peer Peers/Tracker
| |
| PPSP Message |
|<-----------------------------------------------|
| |
| Error Information |
|----------------------------------------------->|
| |
| |
Figure 2: Error Handling
PPSP.ERR.REQ-2: A tracker, when is operating close to its capacity
limit, MUST be able to inform the peers about its overload status,
and reject the following PPSP messages from the peers or redirect the
following PPSP message to other trackers.
5. IANA Considerations
This document presently raises no IANA considerations.
Zong, et al. Expires April 25, 2010 [Page 8]
Internet-Draft PPSP Requirements October 2009
6. Security Considerations
The scope of this section is to analyze the security threats and
provide the requirements for PPSP. While P2P streaming system
prevails in recent years, an important but less studied problem is
security.
PPSP.SEC.REQ-1: PPSP must ensure that only authorized users can
access the original media in the P2P streaming system. This can be
achieved by defining or adopting such mechanisms as user
authentication and/or key management scheme.
PPSP.SEC.REQ-2: Confidentiality of the streaming data should be
supported and the corresponding key management scheme must scale well
without degrading the system performance.
PPSP.SEC.REQ-3: PPSP must provide an option to encrypt data exchange
among PPSP entities.
PPSP.SEC.REQ-4: PPSP must prevent stream pollution attacks. In the
stream pollution attack, the attacker mixes into the stream bogus
chunks, or declare the chunks it doesn't have.
Such an attack will degrade the quality of the rendered media at the
receiver. For example, in a P2P live video streaming system a
polluter can introduce corrupted chunks. Each receiver integrates
into its playback stream the polluted chunks it receives from its
other neighbors. Since the peers forwards chunks to other peers, the
polluted content can potentially spread through much of the P2P
streaming network.
PPSP.SEC.REQ-5: PPSP must have mechanisms to limit potential damage
caused by malfunctioning and badly behaving peers in the P2P
streaming system. In addition there must be a way to identify badly
behaving peers, and exclude or reject them from the P2P streaming
system.
PPSP.SEC.REQ-6: PPSP must prevent peers from exhausting the P2P
streaming system's available resource, e.g. processing capacity,
bandwidth, etc.
Given the prevalence of DoS attacks in the Internet, it is important
to realize that a similar threat could exist in a large-scale
streaming system where attackers are capable of consuming a lot of
resources with just a small amount of effort.
PPSP.SEC.REQ-7: PPSP should minimize the dependency on reachability
of centralized servers.
Zong, et al. Expires April 25, 2010 [Page 9]
Internet-Draft PPSP Requirements October 2009
PPSP.SEC.REQ-8: PPSP Peers must be able to participate in the
streaming network in private manner without any aspect of the peers
privacy violated.
PPSP.SEC.REQ-9: Existing security mechanisms should be re-used as
much as possible in PPSP, to avoid developing new security
mechanisms.
PPSP.SEC.REQ-10: Security mechanisms of PPSP should not limit the
scalability, performance and reliability of the P2P streaming system.
7. Acknowledgements
The authors would like to thank many people for discussing P2P
streaming. We would particularly like to thank: Haibin Song,
Xingfeng Jiang from Huawei Technologies, Hui Zhang from NEC Labs, Jun
Lei from University of Goettingen, James Seng from PPLive, Das
Saumitra from Qualcomm, Lin Xiao and Christian Schmidt.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[WWW.PPLive]
"www.pplive.com".
[WWW.PPStream]
"www.ppstream.com".
[WWW.UUSee]
"www.uusee.com".
[WWW.Pando]
"www.pando.com".
[WWW.YouTube]
"www.youtube.com".
[WWW.Tudou]
"www.tudou.com".
Zong, et al. Expires April 25, 2010 [Page 10]
Internet-Draft PPSP Requirements October 2009
[Survey] Zong, N. and X. Jiang, "Survey of P2P Streaming",
IETF PPSP BoF, November 2008.
[ProbSta] Zhang, Y., "Problem Statement of P2P Streaming Protocol
(PPSP)", IETF PPSP BoF, November 2008.
[P2PLive] Guo, Y., Liang, C., and Y. Liu, "Adaptive Queue-based
Chunk Scheduling for P2P Live Streaming", IFIP
Networking Proceedings, May 2008.
[LiveStream]
Pascual, V., "Live Streaming over P2PSIP", International
SIP Conference 10th Edition, January 2009.
[I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-01 (work in
progress), December 2008.
[PPSPPS] Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang,
"PPSP Problem Statement",
draft-zhang-ppsp-problem-statement-05 (work in progress).
Authors' Addresses
Ning Zong (editor)
Huawei Technologies
Phone: +86 25 84565866
Email: zongning@huawei.com
Yunfei Zhang
China Mobile Communication Corporation
Phone: +86 13601032119
Email: zhangyunfei@chinamobile.com
Victor Pascual
Tekelec
Email: victor@iptel.org
Zong, et al. Expires April 25, 2010 [Page 11]
Internet-Draft PPSP Requirements October 2009
Carl Williams
Consultant
Palo Alto, California 94306
Email: carlw@mcsr-labs.org
Zong, et al. Expires April 25, 2010 [Page 12]