PPSP Y. Zhang Internet Draft China Mobile N.Zong HuaweiTech G.Camarillo Ericsson J.seng PPlive R.Yang Yale University Intended status: Informational September 25, 2011 Expires: March 2012 Problem Statement of P2P Streaming Protocol (PPSP) draft-ietf-ppsp-problem-statement-05.txt Abstract P2P streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes standard signaling protocols called PPSP and discusses the scope and use cases of PPSP. zhang Expires March 25, 2012 [Page 1] Internet-Draft Problem Statement of PPSP September 2011 Status of this Memo This Internet-Draft is submitted 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 March 25, 2009. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. zhang Expires March 25, 2012 [Page 2] Internet-Draft Problem Statement of PPSP September 2011 Table of Contents 1. Introduction ................................................ 4 2. Terminology and concepts ..................................... 6 3. Problem statement ........................................... 8 3.1. Difficulties for ISPs in deploying P2P caches ........... 8 3.2. Difficulties in building open streaming delivery infrastructure .............................................. 8 3.3. Difficulties in mobile and wireless environment .......... 9 3.4. Difficulties for resource-constraint terminals to run multiple background programs at the same time ............... 10 4. PPSP:Standard peer to peer streaming protocols .............. 11 5. Use cases of PPSP .......................................... 14 5.1. Worldwide provision of open P2P live streaming services . 14 5.2. CDN supporting P2P streaming ........................... 15 5.3. PPSP supporting cross-screen streaming in heterogeneous environment ................................................ 16 5.4. Supporting P2P streaming in cellular mobile network ..... 16 5.5. Cache service supporting P2P streaming ................. 17 6. Security Considerations ..................................... 19 7. IANA Considerations ........................................ 20 8. Acknowledgments ............................................ 21 9. References ................................................. 22 9.1. Normative References ................................... 22 9.2. Informative References ................................. 22 zhang Expires March 25, 2012 [Page 3] Internet-Draft Problem Statement of PPSP September 2011 1. Introduction Streaming traffic is among the fastest growing traffic on the Internet. As Cisco Visual Network Traffic index measured, video streaming already generates the largest volume of Internet traffic in the year of 2010, and the percentage is expected to rise to as high as 91% of the total Internet traffic by 2014[Cisco]. There are two basic architectures for delivering streaming traffic on the Internet: the client-server paradigm and the peer to peer (P2P) paradigm [Survey]. The basic advantage of the P2P paradigm is its scalability and fault tolerance against failures of centralized infrastructures. As an example, PPLive [PPLive], one of the largest P2P streaming vendors, is able to distribute large-scale, live streaming programs such as the CCTV Spring Festival Gala to more than 3 million users with only a handful of servers. It can also deliver VoD streaming to a scale of some hundred of thousands simultaneous users using the same structure and similar protocols [VoD]. The effect of P2P technologies is also well demonstrated in delivering real and VoD streaming effectively in current practice like CNN [CNN], PPstream [PPStream],UUSee [UUSee]and CNTV[CNTV]. The latest release of Adobe Flash, a major platform of streaming distribution in the Internet, has also introduced Cirrus [Cirrus], a peer assisted data exchange mode. One point that should also be noted is that P2P approach requires more resources and computational power on the clients (when compared to client-server architecture), as well as a lot of clients to participate in the P2P network for the network to be efficient. This is less challenging for highly increasing capability on hardware. What's more, along with the new players like CDN providers (e.g.,Akamai NetSession [Akamai], ChinaCache[ChinaCache]) joining in the effort of using P2P streaming delivery in providing their content, the P2P streaming ecosystem is becoming more complex with diverse players varying from the source, infrastructure side, edge delivery side even to the heterogeneous kinds of terminals. Given the increasing integration of P2P streaming into the global content delivery infrastructure, the lacking of an open, standard P2P streaming signaling protocol suite becomes a major missing component in the protocol stack. Almost all of these systems use their proprietary signaling protocols. Multiple, similar but proprietary signaling protocols result in repetitious development efforts for new systems, and the lock-in effects lead to substantial difficulties in their integration. For example, in the enhancement of existing caches and CDN systems to support P2P streaming, open protocols may reduce zhang Expires March 25, 2012 [Page 4] Internet-Draft Problem Statement of PPSP September 2011 the complexity of the interaction with different P2P streaming applications. In this document we propose an open P2P streaming protocol named PPSP, to standardize signaling operations on two important components, peer and tracker in P2P streaming systems for information exchange. The problems of proprietary signaling protocols and benefit of PPSP are explained further in section 3. 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 protocols on distributed resource location, traffic localization, and streaming control and data transfer mechanisms for building a complete streaming system or updating /integrating existing cache/CDN to support P2P streaming delivery. zhang Expires March 25, 2012 [Page 5] Internet-Draft Problem Statement of PPSP September 2011 2. Terminology and concepts Chunk: A chunk is a basic unit of partitioned streaming. Peers may use a chunk as a unit of storage, advertisement and exchange among peers [VoD]. Note that a streaming system may use different units for advertisement and data exchange, using chunks during data exchange, and a larger unit such as a set of chunks during advertisement. Content Distribution Network (CDN): A CDN node refers to a network entity that is deployed in the network (e.g., at the network edge or data centers) to store content provided by the original servers, and serves content to the clients located nearby topologically. Client: A client refers to the service requester in client/server computing paradigm. In this draft a client refers to a participant in a P2P streaming system that only receives streaming content. In some cases the node is not eligible to be a peer without enough computing and storage capability is acting as a client. It can be viewed as a specific kind of peer. Live streaming: It refers to a scenario where all clients receive streaming content for the same ongoing event. It is desired that the lags between the play points of the clients and that of the streaming source be small. P2P cache: A P2P cache refers to a network entity that caches P2P traffic in the network, and either transparently or explicitly as a peer distributes content to other peers. Peer: A peer refers to a participant in a P2P streaming system that not only receives streaming content, but also stores and uploads streaming content to other participants. PPSP: The abbreviation of Peer-to-Peer Streaming Protocols. PPSP refer to the key signaling protocols among various P2P streaming system components, including the tracker and the peer. Swarm: A swarm refers to a group of peers who exchange data to distribute the same content (e.g. video/audio program, digital file, etc) at a given time. Tracker: A tracker refers to a directory server which maintains a list of peers which participate in a specific video channel or in the distribution of a streaming file, and answers queries from peers for zhang Expires March 25, 2012 [Page 6] Internet-Draft Problem Statement of PPSP September 2011 peer lists. The tracker is a logical component which can be centralized or distributed. Video-on-demand (VoD): It refers to a scenario where different clients may watch different parts of the same recorded media with downloaded content. zhang Expires March 25, 2012 [Page 7] Internet-Draft Problem Statement of PPSP September 2011 3. Problem statement The problems imposed by proprietary signaling for P2P streaming applications are listed as follows. 3.1. Difficulties for ISPs in deploying P2P caches Facing with many P2P streaming applications, ISPs are witnessing a big traffic tension on their backbone and inter-networking points.P2P caches are used to reduce the traffic by dynamically storing the frequently accessed streaming content (maybe in chunk or in file granularity). However, the cache nodes need to execute DPI (deep packet inspection) for identifying different P2P streaming systems. Multiple ever changing proprietary P2P streaming protocols require the P2P cache updating its matching library constantly which increases the operator's cost dramatically. With PPSP, P2P caches can detect P2P streaming applications much easier without needing to update its library, as there is only a single protocol to be detected and not a potentially unknown set of proprietary P2P protocols. This reduces the ISP workload to a large extent. Note that using standard PPSP won't hurt current P2P streaming vendors: Firstly, the openness of signaling interaction makes it easy to integrate them with ISP's caches for better user experience, say, smaller delay of the play. Secondly, -with PPSP, different applications use PPSP for signaling, but implement something system specific on top of that. That is to say, different P2P streaming systems compete on "on top" things, like scheduling algorithms, which is independent of how the peers exchange chunk availability. In other words, different systems can have quite different scheduling algorithms with same tracker/peer protocol, which is easier to be open. 3.2. Difficulties in building open streaming delivery infrastructure More and more efforts are seeking for building an open global streaming delivery infrastructure, where P2P-type is accounting for a large portion. However if current multiple proprietary protocols continue to work, there will exist lots of specific and independent systems to deliver vast of same streaming content. This brings more burdens for identifying and sharing the same contents, increases the storage, forwarding and maintenance cost in the intermediate nodes for repeated content. This will definitely increase the cost of streaming distribution and causes possible congestion in the network. zhang Expires March 25, 2012 [Page 8] Internet-Draft Problem Statement of PPSP September 2011 Consider a case where source vendors cooperate with 3rd party CDN provider. Such integration is already practiced by UUSee[UUSee], RayV[RayV] and Forcetech[Forcetech]. The effect has been verified to improve the total performance of P2P streaming (e.g., with lower latency) by providing more stable "super peers" and reduce traffic for ISP [CDN+P2P] [RFC 5693].However, there are substantial obstacles for CDN nodes supporting proprietary P2P streaming protocols [HPTP]. Unlike the Web where all kinds of the infrastructure devices have been already equipped with standard HTTP protocol, an open CDN supporting various P2P streaming applications need to understand and keep updated on various protocols. Similar to the caching case in Section 3.1, this introduces complexity and deployment cost. With PPSP, CDN nodes can be designed to inter-operate with other devices by only standard protocols, reducing the case by case negotiation between the P2P streaming providers and CDN providers.On the other side, the interface between CDN nodes and user peers can be either HTTP or PPSP. 3.3. Difficulties in mobile and wireless environment Mobility and wireless are becoming increasingly important features in today's Internet. It is predicted that by the end of 2012, the number of mobile Internet users will surpass that of fixed Internet users in China [Statistics]. Mobile streaming has becoming a key offering. In Korea the number of mobile TV subscriber has reached seventeen millions, accounting for one third of the mobile subscribers. During the 2008 Beijing Olympic Games, more than one million users enjoyed mobile TV service. There are more and more studies exploring P2P streaming in mobile and wireless networks [Mobile Streaming1] [Mobile Streaming2]. However it's difficult to copy current P2P streaming protocols in mobile and wireless networks. Current protocols are designed mainly for fixed Internet. Although smart handsets are more eligible to be peers with much better bandwidth and higher CPU frequency, larger storage and memory than before, peer selection is more challenging which needs more information to exchange during the tracker/peer and peer/peer communications: First, in mobile and wireless networks, the connections are unsteady, lower and costly(esp. in uplink). The trackers and peers may need more information, compared to fixed Internet, like packet loss rate, peer battery status and processing capability for peer selection. Note that not all mobile nodes are eligible to be peers. The new-added information should help the tracker/peer to make the decision. Second, current practices often use a "bitmap" message to exchange chunk availability among peers/trackers. The message is often of some kilobytes size and zhang Expires March 25, 2012 [Page 9] Internet-Draft Problem Statement of PPSP September 2011 relatively frequent to exchange. In the mobile networks, the bandwidth is scarce and a reasonable optimization is to reduce the message size, which maybe requires a new expression on "bitmap". Third, mobility issue. When a peer is moving and the IP address changes, the on-going connection and transmission between peers may be affected. Therefore such information should be reported in time, which is not addressed in current practices. PPSP should investigate these factors for a practical converged network from the beginning of the design. 3.4. Difficulties for resource-constraint terminals to run multiple background programs at the same time Private protocols may require a terminal to install different software for different applications. Note that for many client software, even it's not used by the users right now, the background program may be invoked to facilitate other peers for free data delivery assistance. In other words, there will be multiple background programs running at the same time. However it may be difficult to invoke multiple programs in a resource constraint peer like mobile handsets or set-top box. The limited CPU, storage and memory often limit the total number of concurrent threads and processes. Taking storage for example, according to [PPStream][UUSee][PPLive Design], the buffer of each peer's hard disk contributed to the system is at least 1GB. If each mobile peer, like iPhone (version 1) runs two such background applications at the same time, the storage cannot be shared for different applications and it will consume one fourth of all its storage (8 GB), leaving other data with fewer storage. PPSP can help to reduce the resource consumption on resource constraint devices, such as STBs or mobile phones, by reusing a PPSP base library and potentially other optimizations. zhang Expires March 25, 2012 [Page 10] Internet-Draft Problem Statement of PPSP September 2011 4. PPSP:Standard peer to peer streaming protocols The objective of the PPSP working group is to design a unified peer- to-peer streaming protocol (PPSP) to address the problems discussed in the preceding sections. There are basically two kinds of P2P streaming systems, pull-based and push-based. In pull-based P2P streaming systems, a centralized tracker or distributed trackers maintains information about which peers are in which swarms and answers the peers' query on such information with a peer-list. After receiving the message, the peer can connect with the candidates in a swarm, exchange its content availability in its memory or storage (depending on it's real-time or VoD streaming) with other peers and then retrieve the wanted streaming data. The swarm is a mesh topology. Most of the current practices are belonging to this genre. The advantages of pull-based mode are its robustness to the peer churn and acceptable latency for a smooth play. In push-based P2P streaming systems, there is a head node maintaining the topology, e.g., a tree. The peers in this topology share the same interest on content. The signaling and data distribution are both based on this topology. For one program or video file, the peer queries the head node for its location to join and the head node replies with a peer-list(potentially in a recommended order). After receiving this peer-list, the peer can connect with the candidates for being a node in certain place of the topology and receive the data along this topology without the need of exchanging content availability with its siblings. In this sense the head node is acting as the tracker. The push mode has the advantages of lower latency but the topology is fragile to the peer churn. Few commercially deployed systems use this mode. A more practical mode is a hybrid pull-push mode where the peers exchange content availability with its siblings for retrieving requsted data. In live streaming, all peers are interested in the media coming from an ongoing event, which means that all peers share nearly the same streaming content at a given point of time. In live streaming, some peers may store the live media for further distribution, which is known as TSTV (time-shift TV), where the stored media are separated into chunks and distributed in a VoD-like manner. zhang Expires March 25, 2012 [Page 11] Internet-Draft Problem Statement of PPSP September 2011 In VoD, different peers watch different parts of the recorded media content during a past event. In this case, each peer keeps asking other peers which media chunks are stored in which peers, and then gets the required media from certain/selected peers. To sum up, in essence, there are two important entities in P2P streaming, i.e., trackers and peers in P2P streaming systems. PPSP is targeted to standardize the signaling protocols in this tracker-based architectures for supporting both live and VoD streaming. In detail, PPSP designs a protocol for signaling between trackers and peers (the PPSP "tracker protocol") and a signaling protocol for communication among the peers (the PPSP "peer protocol") as shown in Figure 1. The two protocols enable peers to receive streaming data within the time constraints required by specific content items. The tracker protocol handles the initial and periodic exchange of meta information between trackers and peers, such as peer-list and content information. The peer protocol controls the advertising and exchange of media data between the peers. Note that in the pull mode and hybrid pull-push mode, both tracker protocol and peer protocol can be used; while in the push mode, only tracker protocol is used. zhang Expires March 25, 2012 [Page 12] Internet-Draft Problem Statement of PPSP September 2011 +------------------------------------------------+ | | | +--------------------------------+ | | | Tracker(Head Node) | | | +--------------------------------+ | | | ^ ^ | |Tracker | | Tracker |Tracker | |Protocol| | Procotol |Protocol | | | | | | | V | | | | +---------+ Peer +---------+ | | | Peer |<----------->| Peer | | | +---------+ Protocol +---------+ | | | ^ | | | |Peer | | | |Protocol | | V | | | +---------------+ | | | Peer | | | +---------------+ | | | | | +------------------------------------------------+ Figure 1 PPSP System Architecture zhang Expires March 25, 2012 [Page 13] Internet-Draft Problem Statement of PPSP September 2011 5. Use cases of PPSP 5.1. Worldwide provision of open P2P live streaming services The cooperative vendors can easily expand the broadcasting scale with PPSP. In figure 2 shows the case that vendor A broadcasts the program with the help of vendor B and vendor C for a wider coverage. The interaction between vendor A's tracker and vendor B and vendor C's super-nodes (SN in short) can be normalized using tracker protocol; and peer protocol can be used among SNs/peers spread in different vendors. +-------------------------------------------------------------------+ | | | +------------------+ | | +------------>| A's Tracker |<----------+ | | | +------------------+ | | | Tracker| ^ ^ | | | Protocol| Tracker| |Tracker |Tracker | | | Protocol| |Protocol |Protocol | | | | | | | | | | | | | | v v v v | | +------+ Peer +------+ +------+ +------+ | | | B's |<------->| B's | | C's | | C's | | | | SN1 |Protocol | SN2 | | SN1 | | SN2 | | | +------+ +------+ +------+ +------+ | | ^ ^ ^ ^ | | | | | | | | | | Peer Protocol Peer Protocol| | | | Peer | +-------------+ +--------------+ |Peer | | Procotol| | | |protocol| | | | | | | | | | | | | | | | | | | | v v v v | | +------+ Peer +------+ +---------+ Peer +---------+ | | | A's |<------> | B's | |A's |<------> |C's | | | | User1|Protocol | User2| | User1 |Protocol | User2 | | | +------+ +------+ +---------+ +---------+ | | | +-------------------------------------------------------------------+ Figure 2 Cooperative Vendors Interaction zhang Expires March 25, 2012 [Page 14] Internet-Draft Problem Statement of PPSP September 2011 5.2. CDN supporting P2P streaming This scenario is similar to use case 1 except that the intermediate SNs are replaced by 3rd party CDN surrogates with PPSP. The P2P streaming vendors A and B can rent CDN surrogates to provide higher QoS services for VIP users than services provides by only ordinary peers. The interaction among these network entities are shown in Figure 3. The CDN nodes talk with the different trackers and peers with the uniform Tracker and peer protocols. It can also communicate with end users using HTTP for legacy equipments. The internal interaction of CDN nodes can be executed by either original internal protocol or new peer protocol. The latter is used when building a new CDN system supporting streaming applications with low cost deploying P2P delivery inside the network. +-------------------------------------------------------------------+ | | | +-------------+ +--------------+ | | +----->| A's Tracker | | B's Tracker |<---+ | | | +-------------+ +--------------+ | | | Tracker| ^ ^ ^ ^ | | | Protocol| Tracker| |Tracker | |Tracker |Tracker | | | Protocol| |Protocol| |Protocol |Protocol| | | | | | | | | | | | | | | | | | v v | | v v | | +------+ Peer +------+| | +------+Internal+------+ | | | CDN |<------>| CDN || | | CDN |<-----> | CDN | | | | Node1|Protocol| Node2|| | | Node3|Protocol| Node4| | | +------+ +------+| | +------+ +------+ | | ^ ^ | | ^ ^ | | | | | | | | | | | | Peer Protocol | | HTTP | | | | Peer | +-------------+ | | +------+ | Peer | | Procotol| | | | | Protocol |protocol| | | | +-+ | | | | | | | | | | | | | | | | | | | | | v v v v v v | | +------+ Peer +------+ +---------+ Peer +---------+ | | | A's |<------> | A's | |B's |<------> |B's | | | | User1|Protocol | User2| | User3 |Protocol | User4 | | | +------+ +------+ +---------+ +---------+ | | | +-------------------------------------------------------------------+ Figure 3 CDN Supporting P2P Streaming zhang Expires March 25, 2012 [Page 15] Internet-Draft Problem Statement of PPSP September 2011 5.3. PPSP supporting cross-screen streaming in heterogeneous environment In this scenario PC, Setbox/TV and mobile terminals from both fixed network and mobile network share the content they store/cache. Peers from heterogeneous networks With PPSP Peers can identify the types of access networks, average load, peer abilities and get to know what content other peers have (potentially with the conversion of the content availability expression in different networks) even in different network conditions as shown in Figure 4. These information will play an important role on selecting suitable peers, e.g., a PC or STB node is more likely to be selected to provide stable content for mobile nodes; a mobile peer within a high-load base station is unlikely to be selected, which may lead to higher load on the base station. +-------------------------------------------------------------------+ | | | Tracker Protocol +---------+ Tracker Protocol | | +-------------> | Tracker |<------------------+ | | | +---------+ | | | | ^ | | | | | | | | | | | | | V | V | | +------+ | +------------+ | | | STB | Tracker Protocol |Mobile Phone| | | +------+ | +------------+ | | ^ | ^ | | | | | | | | | | | | | V | | | |Peer Protocol +---------+ Peer Protocol | | | +-------------> | PC |<------------------+ | | +---------+ | | | +-------------------------------------------------------------------+ Figure 4 Heterogeneous P2P Streaming Interaction with PPSP 5.4. Supporting P2P streaming in cellular mobile network In a cellular mobile environment like 3G or 4G, with the increase in bandwidth and smart mobile terminal capabilities, P2P (including P2P zhang Expires March 25, 2012 [Page 16] Internet-Draft Problem Statement of PPSP September 2011 streaming) is easier to be realized than before. In a provincial network of China Mobile, P2P has accounted for more than 30 percentage of the traffic, ranked second. Note that the mobile terminals are not compulsorily to be peers. Here they act as clients. Network peers who are deployed by the ISPs or operators and mobile peers with WiFi connections are more likely to be selected. For example, in 3GPP, there is a P2P CDS work item working on the requirement of mobile operators to prefer use deployed network-side equipments (e.g., serving gateways or GGSNs, one access point from cellular mobile network to the Internet) to act as super- peers when there are no enough eligible peers to realize P2P streaming[P2P CDS]. Because they are deployed by the operators, the stability and storage size are better guaranteed than ordinary peers. Similar with case 5.3, PPSP tracker protocol will help to identify and return the super-peers in the peer-list with preference. If mobile terminals are not eligible to be peers, they can simply receive data from these super-peers without contributing any data to others. 5.5. Cache service supporting P2P streaming As discussed in the Section 3, deploying cache nodes at the network edges can greatly decrease the inter-network traffic and increase user experience in streaming service. With PPSP, the cache nodes can identify the P2P streaming genre even it may include different applications. When a peer requests the streaming data, cache detects the request and requests the frequent visited content (or part of) to the original tracker as a normal peer. The tracker replies with (outward) peers. After the cache connectes with the peers, it can report what it cache to the provider's tracker like a normal peer and serve other requesting peers inside to reduce the cross-ISP traffic as shown in Figure 5. The cache nodes needn't update their library when new applications supporting PPSP are introduced, which enable the cache nodes spend less cost to support more applications. zhang Expires March 25, 2012 [Page 17] Internet-Draft Problem Statement of PPSP September 2011 +----------------------------------------------------------------+ | | | 0:Tracker Protocol +---------+ | | +----------------> | Tracker | | | | +---------+ | | | ^ | | | | | | | 2: | Tracker Protocol | | | | | | | | | | | +---------|-------------------------------------| | | | V | | | | +---------+ | | | +----------|---> | Cache |<-------------------+ | | | | | +---------+ 1,4: Tracker/Peer| | | | |3: Peer | Protocol | | | | | Protocol | | | | | | | | | | | | | | | | V V | V | | +-----------+ | ISP Domain +------------+ | | | Outward | | | Inside | | | | Peer | | | Peer | | | +-----------+ | +------------+ | +----------------------------------------------------------------+ Figure 5 Cache Service Supporting Streaming with PPSP zhang Expires March 25, 2012 [Page 18] Internet-Draft Problem Statement of PPSP September 2011 6. Security Considerations This document discusses the problem statement around peer-to-peer streaming protocols without specifying the protocols. The protocol specification is deferred to other documents under development in the PPSP working group. However we believe it is important for the reader to understand areas of security caused by the p2p nature of the proposed solution. The main issue is the usage of untrusted entities (peers) for service provisioning. Malicious peers may, for example: - Issue denial of service (DOS) attacks to the trackers by sending large amount of requests with the tracker protocol; - Issue fake information on behalf of other peers; - Issue fake information about available content; - Issue fake information about chunk availability; Malicious peers/trackers may, for example: - Issue reply instead of the regular tracker (man in the middle attack). The PPSP protocol specifications, e.g., the tracker protocol and the peer protocol, will document the expected threats and how they will be mitigated for each protocol, but also considerations on threats and mitigations when combining both protocols in an application. This will include privacy of the users, protection of the content distribution, but not protection of the content by Digital Rights Management (DRM). zhang Expires March 25, 2012 [Page 19] Internet-Draft Problem Statement of PPSP September 2011 7. IANA Considerations This document has no actions for IANA. zhang Expires March 25, 2012 [Page 20] Internet-Draft Problem Statement of PPSP September 2011 8. Acknowledgments We would like to acknowledge the following people who provided review, feedback and suggestions to this document: M. Stiemerling; C. Schmidt; D. Bryan; E. Marocco; V. Gurbani; R. Even; H. Zhang; L. Xiao; C. Williams; V. Pasual; D. Zhang; J. Lei. This document was prepared using 2-Word-v2.0.template.dot. zhang Expires March 25, 2012 [Page 21] Internet-Draft Problem Statement of PPSP September 2011 9. References 9.1. Normative References [RFC 5693], Application-Layer Traffic Optimization (ALTO) Problem Statement, E. Marocco et al, http://datatracker.ietf.org/doc/rfc5693/ 9.2. Informative References [Cisco] Cisco Visual Networking Index: Forecast and Methodology, 2009-2014, http://www.cisco.com/en/US/solutions/collateral/ns341/ns525 /ns537/ns705/ns827/white_paper_c11- 481360_ns827_Networking_Solutions_White_Paper.html [PPLive] www.pplive.com [VoD] Yan Huang et al,Challenges, "Design and Analysis of a Large- scale P2P-VoD System", Sigcomm08. [CNN] www.cnn.com [PPStream] www.ppstream.com [UUSee] www.uusee.com [CNTV] www.cntv.com [Cirrus] labs.adobe.com/technologies/cirrus/ [Akamai] Peer-to-Peer Systems, Rodrigo Rodrigues et al, Communications of the ACM,Vol. 53 No. 10, Pages 72-82. http://cacm.acm.org/magazines/2010/10/99498-peer-to-peer- systems/fulltext. [ChinaCache] http://www.redorbit.com/news/technology/813722/rawflow_part ners_with_chinacache_creating_asias_largest_p2p_powered_liv e/ [Survey] Yong Liu et al, "A survey on peer-to-peer video streaming systems", Peer to Peer Networking and Applications (2008) Volume 1, Number 1,:18-28,Springer. zhang Expires March 25, 2012 [Page 22] Internet-Draft Problem Statement of PPSP September 2011 [RayV] http://www.rayv.com [Forcetech] http://www.forcetech.net/english/solutions [CDN+P2P] H. Jiang et al,"Efficient Large-scale Content Distribution with Combination of CDN and P2P Networks", International Journal of Hybrid Information Technology, Vol.2, No.2, April, 2009. [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen et al, IPTPS 2007. [Statistics] http://labs.chinamobile.com/news/48283 [P2P CDS] 3GPP TR 22.906, Study on IMS based peer-to-peer content distribution services,http://www.3gpp.org/ftp/Specs/html- info/22906.htm [Mobile Streaming1] Streaming To Mobile Users In A Peer-to-Peer Network,Jeonghun Noh et al,MOBIMEDIA '09. [Mobile Streaming2] J. Peltotalo et al.,"A real-time peer-to-peer streaming system for mobile networking environment", in Proceedings of the INFOCOM and Workshop on Mobile Video Delivery (MoVID '09), April 2009. [PPLive Design] Y. Huang, T. Fu, D. Chiu, J. Lui, and C. Huang ,"Challenges, design and analysis of a large-scale p2p-vod system", ACM SIGCOMM Computer Communication Review, 38(4):375-388, 2008. zhang Expires March 25, 2012 [Page 23] Internet-Draft Problem Statement of PPSP September 2011 Authors' Addresses Yunfei Zhang China Mobile Communication Corporation zhangyunfei@chinamobile.com Ning Zong Huawei Technologies Co., Ltd. zongning@huawei.com Gonzalo Camarillo Ericsson Gonzalo.Camarillo@ericsson.com James Seng PPLive james.seng@pplive.com Richard Yang Yale University yry@cs.yale.edu zhang Expires March 25, 2012 [Page 24]