One document matched: draft-zong-ppsp-reqs-01.txt
Differences from draft-zong-ppsp-reqs-00.txt
PPSP N. Zong, Ed.
Internet-Draft Huawei Technologies
Intended status: Standards Track Y. Zhang
Expires: January 2010 China Mobile Communication
Corporation
V. Pascual
Tekelec
C. Williams
ZTE USA
July 12, 2009
P2P Streaming Protocol (PPSP) Requirements
draft-zong-ppsp-reqs-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 January 12 , 2010.
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.
Zong, et al. Expires January 12, 2010 [Page 1]
Internet-Draft PPSP Requirements July 2009
Abstract
The Peer to Peer Streaming Protocol (PPSP) is a distributed real-time
data retrieval protocol in one-to-many communication. This document
describes the requirements for the PPSP.
Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. P2P Streaming Problem Statement . . . . . . . . . . . . . . . 3
3.1. Motivation for P2P Streaming Protocol . . . . . . . . . . 4
3.2. Definition and Scope of P2P Streaming Protocol . . . . . . 4
3.3. Related Work in IETF . . . . . . . . . . . . . . . . . . . 6
3.3.1. P2PSIP . . . . . . . . . . . . . . . . . . . . . . . . 6
4. P2P Streaming Protocol Requirements . . . . . . . . . . . . . 6
4.1. PPSP General Requirements . . . . . . . . . . . . . . . . 6
4.2. PPSP Signaling Requirements . . . . . . . . . . . . . . . 6
4.3. PPSP Transmission Requirements . . . . . . . . . . . . . . 9
4.4. PPSP Error Handling Requirements . . . . . . . . . . . . . 9
4.5. PPSP Security Requirements . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zong, et al. Expires January 12, 2010 [Page 2]
Internet-Draft PPSP Requirements July 2009
1. Requirements Notation
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
indicate requirement levels for compliant implementations.
2. 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, especially in the winter of the financal crisis
which is being felt all over the world. P2P streaming applications
account for more and more Internet traffic. According to statistics
in a major Chinese Internet Service Provider (ISP), PPlive accounts
10% of the total Internet backbone traffic. In contrast,
Bittorrent's traffic share is about 8% in the ISP's backbone.
Internet streaming is a blooming technology. To accomodate resource
consumption, several architectures based on P2P principles exist. An
important drawback is their incompatibility with standards.
Therefore, it is impossible for various applications (e.g. web
services, IPTV, content distribution, etc) to reuse all or parts of
their components to implement decentralized streaming. Therefore,
it's time to draw up an open and standard P2P Streaming Protocol
(PPSP) in the IETF to achieve broader adoption of P2P streaming and
regulate its behavior from the broader Internet point of view.
Note that the PPSP is in fact at its early stage and there is still a
lot of work to be done in the near future. This version of PPSP
requirements is just a start point and people are kindly invited to
enhance and expand it.
3. P2P Streaming Problem Statement
Zong, et al. Expires January 12, 2010 [Page 3]
Internet-Draft PPSP Requirements July 2009
3.1. Motivation for P2P Streaming Protocol
P2P streaming applications attract more and more users to consume
video content online [WWW.PPLive][WWW.PPStream]. In the case of VoD,
different users watch different parts of the video content so that a
peer normally maintains a buffer to share video content with other
peers. In the case of live content, because all peers are mostly
interested in what is actually happens "now", one possible role of a
peer is to request video content from a live source and then forward
the content to more peers, hence reducing the work load of the live
source [WWW.PPLive].
P2P streaming applications adopt a decentralized streaming
architecture where the media content is shared among peers who not
only download but also upload media content to each other. The
advantages of this decentralized streaming architecture include less
workload (hence reduced cost) on streaming servers, and better
streaming scalability for a large number of users. However, most
current P2P streaming applications make use of proprietary protocols,
making it impossible for various applications (e.g. web services,
IPTV, content distribution, etc) to reuse all or part of their
components to implement decentralized streaming. Therefore, an open
and standard protocol for P2P Streaming Protocol (PPSP) defined in
the IETF would greatly benefit many applications through a
decentralized streaming architecture which enables reduced
infrastructure cost on infrastructure (e.g. media servers) and better
scalability for an increased number of users.
3.2. Definition and Scope of P2P Streaming Protocol
Based on the overview of P2P streaming systems [Survey][ProbSta], the
basic role of PPSP is to define a protocol of locating and
transmitting real-time/VoD data efficiently from multiple sources
with different pieces in peer to peer environment. Therefore PPSP
can be divided into PPSP signaling protocol and transmission protocol
where PPSP signaling protocol will address the issue of distributed
data location. The common process of P2P streaming applications
includes:
a) Peer sends content request/or registration to some centralized
directory server (a.k.a. Tracker) and the server return with a peer
list in which the peer are sharing the requested content. This step
is currently implemented by different P2P applications as private
protocols. It may either be done by P2PSIP RELOAD
[I-D.ietf-p2psip-base] because Dynamic Hash Table (DHT) can manage
the peer list and return the peer list to the requestor.
b) Peer communicate with the peers in the obtained peer list to
Zong, et al. Expires January 12, 2010 [Page 4]
Internet-Draft PPSP Requirements July 2009
exchange the chunk description, i.e. which chunks are located in
which peers, as well as additional peer list having been learned by
other peers. This step should be done by PPSP signaling protocol.
c) Chunk is scheduled, i.e. which chunks are to be transmitted from
which peers. This step is based on internal algorithm (e.g. rarest
first) which should be performed by P2P applications themselves and
thus outof the scope of PPSP signaling protocol.
d) Chunk is transmitted among peers. This step should be done by
PPSP transmission protocol.
Therefore, the core part of PPSP signaling protocol is a set of
messages between peers for:
o the chunk description of each peer (e.g. buffer map);
o list of additional peers to aggregate more peers;
o additional peer status information related to content delivery.
+---------------+
------------>| Tracker/DHT |<---------------------------
| +---------------+ | |
| | |
| Content Request/Registration | |
| (may be done by P2PSIP RELOAD) | |
| | |
| | |
V V |
+--------+ PPSP Signaling +--------+ |
| |<------------------------------->| | |
| Peer | | Peer | |
| |<--------------------- | | |
+--------+ | +--------+ |
PPSP Signaling | V
(Chunk Description, | +--------+
Peer List, | | |
Peer Status, Etc.) ------------------------->| Peer |
| |
+--------+
More Peers
... ...
Figure 1: PPSP Signaling Core
Zong, et al. Expires January 12, 2010 [Page 5]
Internet-Draft PPSP Requirements July 2009
[TODO: Introduce the core part of PPSP transmission protocol]
3.3. Related Work in IETF
3.3.1. P2PSIP
P2PSIP is an IETF WG focusing on the protocols for distributed
resource location [I-D.ietf-p2psip-base]. However, in P2P streaming,
the chunk description of each peer (e.g. buffer map) is highly
dynamic and real-time, which means that simply maintaining this
highly dynamic information in the P2PSIP overlay network may cause
overload of the peers. Therefore, in P2P streaming, it is better to
keep the chunk description locally in distributed peers and use PPSP
signaling to discover which peer has which content.
4. P2P Streaming Protocol Requirements
4.1. PPSP General Requirements
REQ 1: PPSP MUST be able to support streaming services when the
number of users keeps growing, i.e. scale to very large audiences.
Internet video streaming, if it is to compete with classical TV
broadcasting, has to scale to very large audiences (large scale:
hundreds of thousands of users) [LiveStream]. PPSP adopts a
decentralized streaming architecture where the media content is
shared among peers who not only download but also upload media
content to each other.
REQ 2: PPSP MUST be self-adaptive to a large numbers of dynamically
joining and leaving users, i.e. robust to peer churn.
The robustness of a streaming system is required when a large number
of customers dynamically join and leave the system, specially if some
form of video relaying or forwarding for bandwidth saving is
employed. In PPSP, a peer simultaneously contacts with more than one
peer to share media content, thus reducing the impact of peer churn.
4.2. PPSP Signaling Requirements
REQ.1: PPSP signaling MUST be able to carry chunk description (e.g.
buffer map) of the peers.
In order to share content among peers, peers must be able to tell
each other which chunks reside in which peers. That is, PPSP
signaling must carry chunk description of the peers.
Zong, et al. Expires January 12, 2010 [Page 6]
Internet-Draft PPSP Requirements July 2009
Local Peer Peers
| |
| Chunk Description |
|<---------------------------------------------->|
| |
Figure 2: Exchange Chunk Description
One common type of chunk description is called a 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 3: Buffer Map
After a peer receives a buffer map from other peers, the peer can
request one or more chunks that other peers have advertised in the
buffer map.
REQ.2: PPSP signaling MUST be able to negotiate the semantics of
chunk description.
In order for every peer to know the exact meaning of each part of the
chunk description, it is necessary for peers to negotiate the
semantics of chunk description. For instance, the size of each chunk
represented by the buffer map. Note that although the semantics of
chunk description can be specified in a standard manner, it is useful
to apply such negotiation to allow for more flexible interaction
between different applications. For example, some P2P streaming
application schedulers are based on chunks corresponding to size of
mili-seconds while other schedulers are based on the size of seconds.
Local Peer Peers
| |
| Negotiate Chunk Description |
|<---------------------------------------------->|
| |
Figure 4: Negotiaion
Zong, et al. Expires January 12, 2010 [Page 7]
Internet-Draft PPSP Requirements July 2009
Only when these semantic of chunk description are negotiated and
decided among all the peers will every peer be able to share chunk
information with each other, i.e., which chunks are stored in which
peers.
REQ.3: PPSP signaling May carry additional peer list.
Note that the tracker/DHT only return an initial list of peers to new
peer. Some peers may need more peers to connect with and share
content. In order for each peer to know more peers sharing the same
content, it is possible that the peer communicates with the peers in
the current peer list to obtain additional lists which it aggregates
with the current peer list. In this manner, each peer maintains a
list of other peers sharing the same content.
Local Peer Peers
| |
| Additional Peer List |
|<---------------------------------------------->|
| |
Figure 5: Exchange Peer List
REQ.4: PPSP signaling May carry peer status for content delivery
(e.g. bandwidth, work load of the peers).
In addition to the chunk description, peers may want to know other
status information for content delivery. Such status information
should be related to the content delivery, including the peers'
access type, bandwidth, storage, work load, etc. With this
information, a peer can select more appropriate peers for content
sharing based on some content sharing strategies and/or application
requirements.
For some peers deployed by ISP such as those comprising Content
Distribution Network (CDN), PPSP signaling MUST be able to carry peer
information. In this way, CDN will announce its capabilities for
providing streaming content to the peers.
Local Peer Peers
| |
| Peer Status for content delivery |
|<---------------------------------------------->|
| |
Figure 6: Exchange Peer Status
Zong, et al. Expires January 12, 2010 [Page 8]
Internet-Draft PPSP Requirements July 2009
4.3. PPSP Transmission Requirements
REQ 1: PPSP transmission MUST be able to support limited start-up
delay and limited latency between the broadcasting time and the
audience view time [LiveStream].
REQ 2: PPSP transmission MAY support efficient one-to-many data
transport with some extent of fairness assurance and balance between
self-constraint and aggression for network bandwidth.
[TODO: Expand this section]
4.4. PPSP Error Handling Requirements
REQ.1: A peer MUST be able to respond with error information to peers
sending chunk description messages when some information (e.g. chunk
ID) cannot be understood in the message.
In this case, the sending peer may start a negotiation flow to
negotiate the semantics of chunk description.
Local Peer Peers
| |
| Chunk Description |
|<-----------------------------------------------|
| |
| Error Information |
|----------------------------------------------->|
| |
| Negotiate Chunk Description |
|<---------------------------------------------->|
| |
Figure 7: Error Handling
4.5. PPSP Security Requirements
REQ 1: PPSP MUST be able to provide mechanisms to prevent peers from
distributing wrong information, such as claiming they have the chunks
that they don't, or sending out false peer status information.
[TODO: Expand this section]
5. IANA Considerations
This document presently raises no IANA considerations.
Zong, et al. Expires January 12, 2010 [Page 9]
Internet-Draft PPSP Requirements July 2009
6. Security Considerations
The scope of this section is to analyze the security threats and
provide the requirements for the PPSP architecture While peer-to-
peer (P2P) live streaming prevails in recent years, an important
but less studied problem is security.
6.1. PPSP access control Requirement
SEC REQ 1: PPSP must ensure that only authorized users can access
the original media in the P2P live streaming system. This can be
achieved by defining or adopting such mechanisms as user
authentication and/or key management scheme.
Such access control must be secure, scalable, reliable, and
efficient for PPSP live streaming systems.
6.2 PPSP confidentiality Requirement
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.
6.3 PPSP stream pollution prevention requirement
SEC REQ 3: P2PSP must prevent stream pollution attacks. In the
stream pollution attack, the attacker mixes into the stream bogus
chunks. Such an attack will degrade the quality of the rendered
media at the receiver. 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
PPSP streaming network.
6.4 PPSP must prevent various DOS attacks
Given the prevalence of DoS attacks in the Internet, it is
important to realize that a similar threat could exist in a large-
scale PPSP media streaming system where attackers are capable of
consuming a lot of resources with just a small amount of effort.
Below are some PPSP DOS related requirements.
SEC REQ 4: The PPSP system must prevent selfish and malicious peers
to exhaust the system's available upload bandwidth.
Zong, et al. Expires January 12, 2010 [Page 10]
Internet-Draft PPSP Requirements July 2009
SEC REQ 5: The PPSP system must be fault tolerant. Here the PPSP
architecture should make sure that data stored in the network is
persistent in that if other peers fail, data is not lost to those
peers. The attacker should not be able to obtain unlimited
resources in the PPSP streaming network.
SEC REQ 6: The PPSP system should have a mechanism to limit
potential damage caused by malfunctioning and badly behaving nodes
in a PPSP system. It should be possible limit the impact of the
badly behaving nodes on the overall system security. In addition
there should be a way to identify badly behaving nodes, and
exclude or reject them from the PPSP system.
6.5 PPSP must provide privacy of its participants
SEC REQ 7: PPSP security must be able to participate in the PPSP
streaming network without in private manner without any aspect of
the peers privacy violated.
6.6 PPSP should use existing security mechanisms when possible
SEC REQ 8: Existing security mechanisms should be used as much as
possible to protect PPSP functions and components, and avoid the
need for standardizing new mechanisms.
6.7 PPSP Security must not limit scalability or performance
SEC REQ 9: Security should not limit PPSP scalability,
performance and reliability.
6.9 PPSP must provide option for encryption
SEC REQ 10: The PPSP network entities must be provided with an
option to encrypt data exchange with other PPSP network entities.
6.10 PPSP should minimize the dependence on central server
SEC REQ 11: Dependence of reachability of a centralized server
should be minimized.
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.
Zong, et al. Expires January 12, 2010 [Page 11]
Internet-Draft PPSP Requirements July 2009
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".
[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.
Zong, et al. Expires January 12, 2010 [Page 12]
Internet-Draft PPSP Requirements July 2009
Appendix A. Change Log
New Document
Appendix B. Open Issues
[TODO: Fill in]
Authors' Addresses
Ning Zong (editor)
Huawei Technologies
10F, Huihong Mansion, No.91 Baixia Road
Nanjing 210001
China
Phone: +86 25 84565866
Email: zongning@huawei.com
Yunfei Zhang
China Mobile Communication Corporation
Phone: +86 13601032119
Email: zhangyunfei@chinamobile.com
Victor Pasual
Tekelec
Am Borsigturm 11
Berlin D-13507
Germany
Email: victor@iptel.org
Carl Williams
ZTE USA (Consultant)
Palo Alto, CA
USA
Email: carlw@mcsr-labs.org
Zong, et al. Expires January 12, 2010 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 08:56:10 |