idnits 2.17.1 draft-ietf-ppsp-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 13 instances of too long lines in the document, the longest one being 158 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 381 has weird spacing: '...mantics betwe...' == Line 624 has weird spacing: '...on that we li...' == Line 814 has weird spacing: '...Live in a mob...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2010) is 4931 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PPstream' is mentioned on line 130, but not defined == Missing Reference: 'ComCast' is mentioned on line 158, but not defined == Missing Reference: 'P2PStreamSurvey' is mentioned on line 172, but not defined == Missing Reference: 'Survey' is mentioned on line 283, but not defined == Missing Reference: 'HTPT' is mentioned on line 395, but not defined == Missing Reference: 'FIND' is mentioned on line 451, but not defined == Missing Reference: 'Hybrid' is mentioned on line 779, but not defined == Missing Reference: 'AHLSS' is mentioned on line 780, but not defined == Unused Reference: 'Cisco' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'PPStream' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'Octoshape' is defined on line 923, but no explicit reference was found in the text == Unused Reference: 'CoolStreaming' is defined on line 936, but no explicit reference was found in the text == Unused Reference: 'HPTP' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'Challenge' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'Peering CDN' is defined on line 976, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-08 Summary: 3 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPSP Y. Zhang 2 Internet Draft China Mobile 3 Intended status: Standard track N.Zong 4 HuaweiTech 5 G.Camarillo 6 Ericsson 7 J.seng 8 PPlive 9 R.Yang 10 Yale University 11 Expires: April 18, 2011 October 18, 2010 13 Problem Statement of P2P Streaming Protocol (PPSP) 14 draft-ietf-ppsp-problem-statement-00.txt 16 Abstract 18 We propose to standardize the key signaling protocols among various 19 P2P streaming system components including the tracker and the peers. 20 These protocols, called PPSP, are a part of P2P streaming protocols. 21 This document describes the terminologies, concepts, incentives, and 22 scope of developing PPSP, as well as the use cases of PPSP. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 18, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction ................................................ 4 71 1.1. Background ............................................. 4 72 1.2. Research or Engineering ................................ 5 73 1.3. Objective and outline................................... 5 74 2. Terminology and concepts .................................... 6 75 3. Introduction of P2P streaming system ........................ 8 76 4. Problem of proprietary protocols and incentives for developing 77 standard PPSP .................................................. 9 78 4.1. Proprietary signaling leads to difficult interactions in case 79 of multiple parties involved in the delivery ................ 10 80 4.2. Proprietary signaling leads to multiple client software in a 81 terminal .................................................... 11 82 4.3. Proprietary signaling leads to low network resource 83 utilization ................................................. 11 84 4.4. Proprietary signaling doesn't handle well with mobile and 85 wireless environment......................................... 11 86 5. Components of P2P streaming system........................... 13 87 6. Scope of PPSP ............................................... 14 88 6.1. Protocols to be standardized............................ 14 89 6.2. Service types to be considered ..........................15 90 7. Use cases of PPSP ........................................... 16 91 7.1. Worldwide Provision by cooperative P2P Streaming vendors with 92 PPSP......................................................... 16 93 7.2. Three Screen P2P streaming in heterogeneous environment using 94 PPSP ....................................................... 17 95 7.3. CDN supporting streaming ............................... 18 96 7.4. Hierarchical P2P Streaming Distribution with PPSP ...... 19 97 7.5. Serving Gatwway/GGSN acting as Super Nodes assisting P2P 98 streaming delivery in Cellular mobile environment ........... 20 99 8. Security Considerations ..................................... 22 100 9. Acknowledgments ............................................. 22 101 10. Informative References...................................... 23 103 1. Introduction 105 1.1. Background 107 Streaming traffic is among the fastest growing traffic on the 108 Internet. As Cisco Visual Network Traffic index measured, video 109 streaming already generates the largest volume of Internet traffic in 110 2010, and the percentage is expected to rise to as high as 91% of the 111 total Internet traffic in 2014. 113 There are two basic architectures for delivering streaming traffic on 114 the global Internet: the client-server paradigm and the peer to peer 115 (P2P) paradigm [P2PStreamingSurvey]. A particular advantage of the 116 P2P paradigm over the client-server paradigm is its scalability and 117 its fault tolerance against failures of centralized infrastructures. 118 As an example, PPLive [PPLive], one of the largest P2P streaming 119 vendors, is able to distribute large-scale, live streaming programs 120 such as the CCTV Spring Festival Gala to more than 2 million users 121 with only a handful of servers. CNN [CNN] reported that P2P streaming 122 by Octoshape played a major role in its distribution of the 123 historical inauguration address of President Obama. It is well 124 demonstrated in practice that P2P streaming can deliver videos 125 encoded at a rate of at least about 400 Kbps, in the presence of 126 rapid user joins/leaves, with positive user experiences. 128 With the preceding technical advantages, P2P streaming is seeing 129 rapid deployment. Large P2P streaming applications such as PPLive 130 [PPLive], PPstream [PPstream] and UUSee [UUSee] each has a user base 131 exceeding 100 millions. P2P streaming traffic is becoming a major 132 type of Internet traffic in some Internet networks. For example, 133 according to the statistics of a major Chinese ISP, the traffic 134 generated by P2P streaming applications exceeded 50% of the total 135 backbone traffic during the peak time in 2008. In early 2010, CNTV, 136 China National Network Television for CCTV, launched its software 137 named CBox, which supports P2P-based live and VoD programs. The user 138 base of CBox has increased rapidly. During the opening of 2010 FIFA 139 World Cup, the user base of CBox increased 5 times, reaching 3 140 million online users a day and altogether 350 million times view. It 141 is reported that CNTV can support 10 million simultaneous user visits 142 [CNTV]. The latest release of Adobe Flash, a major platform of 143 streaming distribution in the Internet, has introduced Stratus, a 144 client-to-client data exchange mode. There were reports that other 145 major video distributors such as Youtube [youtube] and tudou [tudou] 146 are also conducting trials of using P2P streaming as a component of 147 their delivery infrastructures. 149 Given the increasing integration of P2P streaming into the global 150 content delivery infrastructure, the lacking of an open, standard P2P 151 streaming protocol becomes a major missing component in the Internet 152 protocol stack. Multiple, similar but proprietary P2P streaming 153 protocols result in repetitious development efforts and lock-in 154 effects. On the other hand, we observe a recent trend that more 155 participants beyond traditional P2P streaming vendors are joining the 156 efforts in the development of P2P streaming. Some of these additional 157 participants include infrastructure vendors as Akamai [Akamai], 158 ChinaCache, and ISPs like ComCast [ComCast]. That is, the P2P 159 streaming ecosystem is becoming an increasingly diverse industry with 160 participants from the source, infrastructure (in P2P mode although 161 all the peers are super nodes), delivery and local P2P distribution 162 to the terminals. 164 We argue that proprietary P2P streaming protocols lead to substantial 165 difficulties when integrating P2P streaming as an integral component 166 of a global content delivery infrastructure. For example, proprietary 167 P2P streaming protocols do not integrate well with existing cache and 168 other edge infrastructures. 170 1.2. Research or Engineering 172 As [P2PStreamSurvey] identifies, there exist multiple proprietary P2P 173 streaming systems including PPLive, PPstream, UUsee, Pando, abacast, 174 and Coolstreaming. A natural question to ask is whether the 175 development of P2P streaming is mature and ready for standardization. 176 We admit that P2P streaming will continue to improve and evolve. 177 However, our investigation also shows that existing P2P streaming 178 systems are largely converging, sharing similar architecture and 179 signaling protocols [draft-zhang-ppsp-protocol-comparison- 180 measurement-00]. 182 The role of standardization in P2P streaming systems is to 1) 183 decouple the information exchange with the data delivery so that some 184 most common functions of P2P streaming can use a generic and open 185 protocol; 187 2) standardize the information exchange message so that network and 188 service equipments from different providers can interact with each 189 other to produce a complete P2P streaming system. 191 1.3. Objective and outline 193 Multiple protocols such as streaming control, resource discovery, 194 streaming data transport, etc. are needed to build a P2P streaming 195 system [P2PStreamingSurvey]. We call those protocols P2P streaming 196 protocols. 198 The objective of PPSP(Peer to Peer Streaming Protocol) is to 199 standardize the key signaling protocols among various P2P streaming 200 system components, including the tracker and the peers. Note that the 201 complete set of standard P2P streaming protocols for a complete P2P 202 streaming system could be developed following or in parallel to the 203 development of PPSP. 205 PPSP will serve as an enabling technology, building on the 206 development experiences of existing P2P streaming systems. Its design 207 will allow it to integrate with IETF protocols on distributed 208 resource location, traffic localization, and streaming control and 209 data transfer mechanisms. Regarding to the components it involves, 210 PPSP allows effective integration between the peer index server named 211 tracker and different kinds of peers including edge infrastructure 212 nodes such as cache, gateway and CDN nodes who can act as super peers 213 and ordinary peers. 215 This document describes the terminologies, concepts and common 216 architecture for P2P streaming systems, problems without standardized 217 PPSP (i.e., incentives to standardize PPSP), scope of PPSP as well as 218 its use cases. 220 The rest of this document is organized as follows. In Section 2, we 221 introduce some common terminologies and concepts. In Section 3, we 222 introduce P2P streaming system architecture. In Section 4, we 223 identify the problems without standardized protocols and incentives 224 for developing PPSP protocols. In Section 5 and 6, we describe the 225 software architecture and functional components of P2P streaming 226 systems in order to present the position and scope of PPSP. In 227 Section 7, we list some PPSP use cases. 229 2. Terminology and concepts 231 Chunk: A chunk is a basic unit of partitioned streaming. Peers may 232 use a chunk as a unit of storage, advertisement and exchange among 233 peers [Sigcomm:P2P streaming]. Note that a streaming system may use 234 different units for advertisement and data exchange, using chunks 235 during data exchange, and a larger unit such as a set of chunks 236 during advertisement. 238 Content Distribution Network (CDN) node: A CDN node refers to a 239 network entity that is deployed in the network (e.g., at the network 240 edge or data centers) to store content provided by the original 241 servers, and serves content to the clients located nearby 242 topologically. 244 Live streaming: The scenario where all clients receive streaming 245 content for the same ongoing event. It is desired that the lags 246 between the play points of the clients and that of the streaming 247 source be small. 249 P2P cache: A P2P cache refers to a network entity that caches P2P 250 traffic in the network, and either transparently or explicitly as a 251 peer distributes content to other peers. 253 P2P streaming protocols: P2P streaming protocols refer to protocols 254 such as streaming control, resource discovery, streaming data 255 transport, etc. P2P streaming protocols are needed to build a 256 complete P2P streaming system. 258 Peer/PPSP peer: A peer/PPSP peer refers to a participant in a P2P 259 streaming system that not only receives streaming content, but also 260 stores and uploads streaming content to other participants. 262 PPSP: PPSP refer to the key signaling protocols among various P2P 263 streaming system components, including the tracker and peer. PPSP are 264 a part of P2P streaming protocols. 266 Swarm: A swarm refers to a group of clients (i.e., peers) exchange 267 data to distribute the same content (e.g. video/audio program, 268 digital file, etc) at a given time. 270 Tracker/PPSP tracker: A tracker/PPSP tracker refers to a directory 271 service which maintains a list of peers/PPSP peers storing chunks for 272 a specific channel or streaming file, and answers queries from 273 peers/PPSP peers for peer lists. 275 Video-on-demand (VoD): The scenario where different clients may watch 276 different parts of the same recorded media content during a past 277 event. 279 3. Introduction of P2P streaming system 281 There are multiple available P2P streaming solutions. Some are 282 deployed solutions, while others are still under active study. A 283 survey of existing solutions can be found in [Survey]. 285 In P2P streaming system, there are various swarms with each swarm 286 containing a group of clients sharing same streaming content (e.g. 287 channel, streaming file, etc) at a given time. These clients are 288 called peers, as each client not only receives streaming content, but 289 also stores and uploads streaming content to other clients. In a 290 broad sense of global content delivery infrastructure, peers can 291 include multiple types of entities such as end user applications, 292 caches, CDN nodes, and/or other edge devices. Therefore, the basic 293 functions of a P2P streaming system involve: 295 1) Maintaining information about which peers are in which swarms 296 using some directory service, a.k.a. tracker. 298 2) In each swarm, exchanging information about content availability 299 (e.g. which chunks stored by a peer) among peers, or between 300 tracker and peers. 302 3) In each swarm, exchange of the actual data content among peers. 304 As shown in Figure 1, common information flows in a P2P streaming 305 system include: 307 1) When a peer wants to receive streaming content: 309 1.1) Peer acquires a list of peers in the swarm from the tracker. A 310 swarm can be indexed by a channel ID, streaming file ID, etc. 312 1.2) Peer exchanges its content availability with other peers that 313 are its neighbors. 315 1.3) Peer identifies the peers with desired content and requests for 316 the content from the identified peers. 318 2) When a peer wants to share streaming content with others: 320 2.1) Peer sends information to the tracker about the swarm it belongs 321 to, plus streaming status and/or content availability. 323 +-------------------------------------------------------+ 324 | +-------------------+ | 325 | | Tracker | | 326 | +-------------------+ | 327 | ^ | ^ | 328 | | | |swarms, | 329 | query | | peer list |streaming status | 330 | | | |and/or content | 331 | | | |availability | 332 | | V | | 333 | +-------------+ +------------+ | 334 | | Peer1 |<------->| Peer 2 | | 335 | +-------------+ content +------------+ | 336 | ^ ^ availability | 337 | * | content | 338 | content * |availability | 339 | V V | 340 | +------------+ | 341 | | Peer 3 | | 342 | +------------+ | 343 +-------------------------------------------------------+ 344 Figure 1 Common information flows in P2P streaming system 346 4. Problem of proprietary protocols and incentives for developing 347 standard PPSP 349 We start by considering the success of the Web. It is the standard 350 HTTP protocol that makes it possible to deploy the global content 351 distribution eco-system that consists of not only end devices such as 352 Web servers and Web clients, but also infrastructure devices such as 353 Web caches and CDN nodes. All of these devices communicate through 354 standard protocols and provide substantial benefits to the consumers, 355 the content publishers, and the network infrastructure. 357 As we discussed in Section 1, given the increasing integration of P2P 358 streaming into the global content delivery infrastructure, 359 proprietary P2P streaming protocols not only result in repetitious 360 development efforts and lock-in effect, but also lead to substantial 361 difficulties when integrating P2P streaming as an integral component 362 of a global content delivery infrastructure. The explicit incentives 363 to get rid of the proprietary protocols can be seen from the talks of 364 Johan Pouwelse, scientific director of P2P Next: "?broadcasters from 365 the BBC to Germany's ARD just seem to love the idea of ditching their 366 proprietary platforms [Johan Pouwelse]." 367 Let's take a look of several cases for further problem identification. 369 4.1. Proprietary signaling leads to difficult interactions when 370 multiple parties are involved in the delivery 372 Consider a simplest case. In an open P2P streaming industrial 373 environment, it is possible for different streaming vendors (esp. 374 spread in different regions) to cooperatively deliver a broadcasting 375 event. Suppose PPLive broadcasts live Chinese spring festival gala 376 for American Chinese by Pando networks. At a first sight, this seems 377 reasonable because there are relatively few American Chinese PPLive 378 users. Therefore it can be challenging to achieve efficient P2P 379 delivery by PPLive alone. Utilizing peer resources from a partner 380 such as Pando may achieve higher efficiency. However, different 381 messages and interaction semantics between the two existing systems 382 can lead to challenges in achieving interoperability among PPLive 383 peers and Pando peers. 385 Consider a more complex case where P2P streaming vendors cooperate 386 with CDN providers. Such integration is already practiced by systems 387 such as UUSee, RayV and Forthtech. For P2P streaming, it has been 388 shown that infrastructure devices such as edge caches and CDN nodes 389 can improve the performance of P2P streaming (e.g., lower latency) by 390 providing more stable "super peers" and reduce traffic in ISP network 391 [CDN+P2P] [RFC 5693]. 393 However, there can be substantial obstacles in deploying 394 infrastructure edge devices supporting proprietary P2P streaming 395 protocols [HTPT]. Unlike the Web with the standard HTTP protocol, the 396 current P2P streaming landscape consists of multiple, proprietary P2P 397 streaming protocols differing in their signaling transactions. 398 Consequently, in order to support P2P streaming, the infrastructure 399 devices need to understand and keep updated with various proprietary 400 P2P streaming protocols. This introduces complexity and deployment 401 cost of infrastructure devices. 403 The setting can become more challenging if there are M P2P streaming 404 vendors and N CDN providers for possible cooperative combination. How 405 does a specific CDN node identify different private systems and 406 report to different trackers with proprietary protocols? It seems 407 there are no good ways to address this. The CDN node has to update 408 its protocol through case-by-case negotiations. 410 With standard PPSP, edge caches and CDN nodes can be designed to 411 inter-operate with only the standard protocols, reducing the 412 complexity and cost to support streaming involving P2P. 414 4.2. Proprietary signaling leads to multiple client software in a 415 terminal 417 Because of private protocols, although there can be much commonality 418 among many applications, application developers cannot share common 419 development efforts, leading to repeated efforts and thus wasting 420 work. 422 This may require that a terminal install multiple different software 423 systems for different purposes. For example a user installs CBox for 424 CCTV programming, and PPLive for Japanese and Korean movies. This 425 brings two problems: 427 1) Due to terminal limitations, it may not be possible to install 428 many clients in one machine, esp. for mobile terminals. The limited 429 CPU, storage and cache often limit the concurrent threads and 430 processes. 432 2) Different, independent software system may conduct vicious 433 competitions. In the past, we have even seen that competitors delete 434 each other's software when automatically running a software program. 435 Standard protocols and common components can lead to better co-use. 437 4.3. Proprietary signaling leads to low network resource utilization 439 From the network resource utilization perspective, if we have no 440 standard protocols in designating the resource availability (which is 441 a PPSP task) and every application uses its proprietary protocol for 442 storage and bandwidth usage, then for the same content, many on-the- 443 way data in different applications have to be cached/stored and 444 transferred repeatedly. This wastes storage and causes possible 445 congestion in the network. 447 4.4. Proprietary signaling doesn't handle well with mobile and 448 wireless environment 450 Mobility and wireless are becoming increasingly important features to 451 support in future Internet deployments [GENI], [FIND]. Currently 452 there are more and more mobile and wireless Internet users. By the 453 end of 2009, there are 233 million mobile users in China [CNNIC]. 455 Along with the introduction of mobile and wireless capabilities into 456 the Internet, mobile streaming is becoming a key offered service 457 [MobileTV]. In Korea the number of mobile TV subscriber has reached 458 seventeen millions, accounting for one third of the mobile 459 subscribers. In Italy, there are one million mobile TV users. During 460 the 2008 Beijing Olympic Games, more than one million users utilized 461 China mobile's mobile TV service. 463 Considering that the mobile and wireless nodes have better CPU, 464 memory and storage and the mobile network has better network 465 bandwidth (esp. there are more uplink bandwidth which is wasted for 466 transferring little data in current practice) than before, there is a 467 possibility for the mobile and wireless node to be peers supporting 468 P2P streaming. 470 However, mobile peers may face bigger challenges for supporting P2P 471 streaming with unsteady network connections, less steady power and 472 different media coding for mobile devices. Current proprietary 473 protocols are designed mainly for the fixed Internet and do not 474 address these challenges. We may therefore raise such a question: 475 Shall we let these private protocols to fit in mobile environment 476 system-by-system independently or solve these problems in the design 477 of an open PPSP protocol suite? 479 The answer is obviously clear. It is worth mentioning that the 480 development of PPSP should consider the specific requirements of 481 mobile Internet. For example, the overhead of PPSP should be small in 482 low bandwidth mobile Internet. Also, information exchange in PPSP 483 should support mobility, low battery usage and heterogeneous 484 capabilities of mobile terminals. Systematic requirements on the 485 development of PPSP will be addressed in the requirements documents. 487 5. Components of P2P streaming system 489 +---------------------------------------------------+ 490 | Application Layer | 491 |---------------------------------------------------| 492 | Play-out Layer | 493 | +----------+ +------------+ +-----------+ | 494 | |start/stop| |pause/resume| | FF/rewind | | 495 | +----------+ +------------+ +-----------+ | 496 |-------------------------------------------------- | 497 | Information Layer | 498 | +------------+ +------+ +-----------+ | 499 | |registration| |report| | statistics| | 500 | +------------+ +------+ +-----------+ | 501 |---------------------------------------------------| 502 | Communication Layer | 503 | +---------------------+ +------------------+ | 504 | |tracker communication| |peer communication| | 505 | +---------------------+ +------------------+ | 506 | +-------------+ | 507 | | bootstrap | | 508 | +-------------+ | 509 |---------------------------------------------------| 510 | Transport Layer | 511 +---------------------------------------------------+ 512 Figure 2. Major components of a P2P streaming system. 514 To organize our efforts, we show the components of a complete P2P 515 streaming system in Figure 2. 517 1) The Transport Layer is responsible for data transmission among 518 peers. UDP, TCP or other protocols can be used. 520 2) The Communication Layer includes three components: 522 2.1) Tracker communication is a component that enables each peer to 523 get peer list from the tracker. It may also allow a peer to report 524 content availability to the tracker. 526 2.2) Peer communication is a component that enables each peer to 527 exchange content availability and neighbor peer information as well 528 as send requests other peers for content. 530 2.3) Bootstrap is a component that enables newly joined nodes to 531 obtain tracker information. 533 3) The Information Layer is responsible for peer and content 534 information collection and management. 536 3.1) Registration is a component that enables nodes to register to 537 the system, and publish the content information. The information may 538 include but is not limited to: content description, content type, 539 creation time, node information such as physical location, IP address. 541 3.2) Report is a component that enables peers to report streaming 542 status to the tracker. The information may include peer 543 inbound/outbound traffic, amount of neighbor peers, peer health 544 degree and other streaming parameters. 546 3.3) Statistics is a component that enables trackers to manage the 547 aggregated system information for global control in upload bandwidth 548 consumption, overhead consumption and other tasks. 550 4) The Play-out Layer is responsible for controlling the action of 551 media play (e.g., start, pause, resume, stop, fast-forward, and 552 rewind). 554 5) The Application Layer is the top layer for streaming applications. 556 6. Scope of PPSP 558 6.1. Protocols to be standardized 560 We propose to standardize protocols in PPSP which enable the tracker 561 communication and the peer communication components in the 562 communication layer, as well as the report component in the 563 information layer. These protocols, called PPSP, are key mechanisms 564 involving two important roles - tracker and peer in P2P streaming 565 processes, as addressed in Section 3. These signaling protocols, in 566 essence, aim at standardizing the content information exchange 567 mechanisms among different devices in P2P streaming systems. Note 568 that PPSP is only a part of P2P streaming protocols. The complete set 569 of standard P2P streaming protocols for a complete P2P streaming 570 system could be developed following or in parallel to the PPSP 571 development. 573 Because bootstrap, registration and statistics components are out-of- 574 band mechanisms for streaming processes, they are not in current 575 scope of PPSP. Both transport, play-out and application layers in P2P 576 streaming system are also beyond the current scope of PPSP. 578 Therefore, PPSP includes the PPSP tracker protocol - a signaling 579 protocol between PPSP trackers and PPSP peers, and the PPSP peer 580 protocol - a signaling protocol among PPSP peers. 582 1) PPSP tracker protocol 584 This protocol will define: 586 1.1) Standard format/encoding of information between PPSP peers and 587 PPSP trackers, such as peer list, content availability, streaming 588 status including online time, link status, node capability and other 589 streaming parameters. 591 1.2) Standard messages between PPSP peers and PPSP trackers defining 592 how PPSP peers report streaming status and request to PPSP trackers, 593 as well as how PPSP trackers reply to the requests. 595 Note that existing protocols should be investigated and evaluated for 596 being reused or extended as the messages between tracker and peer. 597 Possible candidates include the use of the HTTP, where the GET method 598 could be used to obtain peer lists, the POST method used for 599 streaming status reports, etc. 601 2) PPSP peer protocol 603 This protocol will define: 605 2.1) Standard format/encoding of information among PPSP peers, such 606 as chunk description. 608 2.2) Standard messages among PPSP peers defining how PPSP peers 609 advertise chunk availability and their neighbor peers information to 610 each other, as well as the signaling for requesting chunks among PPSP 611 peers. 613 Again, existing protocols should be investigated and evaluated for 614 being reused or extended as the messages among peers. Possible 615 candidates include the use of the HTTP, where the GET method could be 616 used to obtain chunk availability, etc. Considering that there can be 617 a large number of peers, the protocol should consider some 618 lightweight (possibly binary) protocols. 620 6.2. Service types to be considered 622 As stated in Section 1, PPSP will serve as an enabling technology and 623 provide tools for building multiple P2P streaming systems. We are not 624 standardizing certain streaming services. The reason that we list 625 service types here is to show we would consider the properties of 626 these services as the requirements for PPSP design. 628 Common service types supported by current P2P streaming systems 629 include live streaming and video-on-demand (VoD). 631 In live streaming, all PPSP peers are interested in the media coming 632 from an ongoing event, which means that all PPSP peers share nearly 633 the same streaming content at a given point of time. In live 634 streaming, some PPSP peers may store the live media for further 635 distribution, which is known as TSTV (time-shift TV), where the 636 stored media are separated into chunks and distributed in a VoD-like 637 manner. 639 In VoD, different PPSP peers watch different parts of the recorded 640 media content during a past event. In this case, each PPSP peer keeps 641 asking other PPSP peers which media chunks are stored in which PPSP 642 peers, and then pulls the required media from some selected PPSP 643 peers. 645 7. Use cases of PPSP 647 7.1. Worldwide Provision by cooperative P2P Streaming vendors with 648 PPSP 650 As stated in section 4.1, the cooperation of P2P Streaming vendors 651 can easily expand the broadcasting scale with standard PPSP. The 652 interactions between cooperative P2P streaming provider A's tracker 653 server and P2P streaming provider B and C's SuperNodes is shown in 654 Figure 3. 656 +-------------------------------------------------------------------+ 657 | | 658 | +------------------+ | 659 | +------------>| A's Tracker |<----------+ | 660 | | +------------------+ | | 661 | Tracker| ^ ^ | | 662 | Protocol| Tracker| |Tracker |Tracker | 663 | | Protocol| |Protocol |Protocol | 664 | | | | | | 665 | | | | | | 666 | v v v v | 667 | +------+ Peer +------+ +------+ +------+ | 668 | | B's |<------->| B's | | C's | | C's | | 669 | | SN1 |Protocol | SN2 | | SN1 | | SN2 | | 670 | +------+ +------+ +------+ +------+ | 671 | ^ ^ ^ ^ | 672 | | | | | | 673 | | | Peer Protocol Peer Protocol| | | 674 | Peer | +-------------+ +--------------+ |Peer | 675 | Procotol| | | |protocol| 676 | | | | | | 677 | | | | | | 678 | | | | | | 679 | v v v v | 680 | +------+ Peer +------+ +---------+ Peer +---------+ | 681 | | A's |<------> | B's | |A's |<------> |C's | | 682 | | User1|Protocol | User2| | User1 |Protocol | User2 | | 683 | +------+ +------+ +---------+ +---------+ | 684 | | 685 +-------------------------------------------------------------------+ 686 Figure 3 Cooperative Vendors Interactions 688 7.2. Three Screen P2P streaming in heterogeneous environment using 689 PPSP 691 This is a use case where PC, Setbox/TV and mobile terminals from both 692 fixed Internet and mobile Internet to construct a peer overlay for 693 streaming content distribution. Using PPSP protocols, peers from 694 different kinds of networks can share and download what they have 695 from each other to form a 3-screen streaming system. 697 +-------------------------------------------------------------------+ 698 | | 699 | Tracker Protocol +---------+ Tracker Protocol | 700 | +-------------> | Tracker |<------------------+ | 701 | | +---------+ | | 702 | | ^ | | 703 | | | | | 704 | | | | | 705 | V | V | 706 | +------+ | +------------+ | 707 | | STB | Tracker Protocol |Mobile Phone| | 708 | +------+ | +------------+ | 709 | ^ | ^ | 710 | | | | | 711 | | | | | 712 | | V | | 713 | |Peer Protocol +---------+ Peer Protocol | | 714 | +-------------> | PC |<------------------+ | 715 | +---------+ | 716 | | 717 +-------------------------------------------------------------------+ 718 Figure 4 Heterogeneous P2P Streaming Interactions with PPSP 720 7.3. CDN supporting streaming 722 This scenario is similar to use case 1 except that this is more like 723 an M to N mapping while use case 1 is more often to be a case by case 724 mapping. This reduces the case by case negotiation between the 725 original provider and multiple CDN providers if otherwise proprietary 726 protocols are used makes it easier for both sides to interoperate. 728 The interactions between the P2P streaming provider's tracker server 729 and CDN surrogates as well as interactions between CDN surrogates are 730 the same as a normal peer as shown in Figure 4. 732 PPSP can be used in: 734 1) Interface between CDN nodes and tracker. This is very useful for a 735 small streaming provider who has no its own CDN surrogates and much 736 money to distribute its stream worldwide. 738 2) New construction of CDN systems by PPSP. This can often occur for 739 an operator or CDN vendor to build a P2P CDN system supporting 740 streaming or file sharing applications with low cost. 742 +-------------------------------------------------------------------+ 743 | | 744 | +------------------+ | 745 | +------------>| Original Tracker |<----------+ | 746 | | +------------------+ | | 747 | Tracker| ^ ^ | | 748 | Protocol| Tracker| |Tracker |Tracker | 749 | | Protocol| |Protocol |Protocol | 750 | | | | | | 751 | | | | | | 752 | v v v v | 753 | +------+ Peer +------+ +------+ +------+ | 754 | | CDN1 |<------->| CDN1 | | CDN2 | | CND2 | | 755 | | POP2 |Protocol | POP1 | | POP1 | | POP2 | | 756 | +------+ +------+ +------+ +------+ | 757 | ^ ^ ^ ^ | 758 | | | | | | 759 | | | Peer Protocol Peer Protocol| | | 760 | Peer | +-------------+ +--------------+ |Peer | 761 | Procotol| | | |protocol| 762 | | | | | | 763 | | | | | | 764 | | | | | | 765 | v v v v | 766 | +------+ Peer +------+ +---------+ Peer +---------+ | 767 | | USA |<------> | USA | |Caribbean|<------> |Caribbean| | 768 | | User1|Protocol | User2| | User1 |Protocol | User2 | | 769 | +------+ +------+ +---------+ +---------+ | 770 | | 771 +-------------------------------------------------------------------+ 772 Figure 5 CDN Supporting P2P Streaming with PPSP 774 7.4. Hierarchical P2P Streaming Distribution with PPSP 776 Hierarchical P2P streaming has many advantages over non-hierarchical 777 streaming such as providing better QoS, e.g., lower start-up latency 778 and service interruption [P2broadcast], higher throughput and lower 779 packets drop ratio [Hybrid], topology-mismatch reduction and better 780 management [AHLSS]. 782 PPSP is useful for clustering the peers because there are abundant 783 node information and content information exchange fetched in the 784 message. 786 7.5. Serving Gatwway/GGSN acting as Super Nodes assisting P2P 787 streaming delivery in Cellular mobile environment 789 In a cellular mobile environment, with the increase in bandwidth and 790 mobile terminal capabilities, P2P streaming is better to be realized 791 than before. Note that we don't have compulsory mobile peers. The 792 network peers and WIFI peers are easier selected. Serving 793 gateway/GGSN, as the gateway for the cellular network to Internet, is 794 more and more viewed as a promising place to add the cache 795 functionality assisting P2P streaming services. Because it's deployed 796 by the operators, the stability and storage size are better 797 guaranteed than ordinary PC. Thus, it is desirable to to select 798 serving gateway/GGSN as the super nodes assisting delivery. The 799 interactions between serving gateway/GGSN and tracker, among serving 800 gateways/GGSNs, and between serving gateway/GGSN and mobile terminal 801 are shown in Figure 6. We name these kinds of serving gateway/GGSN as 802 Mobile Supporting Super Nodes (MSSN). Note that if mobile terminals 803 are not eligible to be a peer, it can use client/server streaming, by 804 simply taking GGSN as a source. 806 There are two basic scenarios in cellular networks: 808 1) Self operational P2P streaming services for mobile operators: PPSP 809 is a suitable protocol for tracker-GGSN and GGSN-mobile nodes 810 interaction. GGSN can be both a super node and a proxy for different 811 mobile terminals with different capabilities. 813 2) Third-party P2P streaming services with optimized localization by 814 GGSN. When introducing a popular P2P streaming application like PPLive in a mobile network, GGSN can coordinate with the third part trackers to cache the content without needing continuous update of the third party protocols. 816 +-------------------------------------------------------------------+ 817 | | 818 | Peer Protocol | 819 | +-------------------+ | 820 | | | | 821 | ,--?. | ,--?. | ,--?. | 822 | .' '. | .' '. | .' '. | 823 | / \ V / \ V / \ | 824 | ' Cellular +------+ Internet +------+ Cellular | | 825 | | Access | MSSN | | MSSN | Access / | 826 | \ Network +------+ +------+ Networks / | 827 | ' /^ ^ \ / \ .' | 828 | '. / | | ' / ' .' | 829 | '. .' | | '.+-------+' '. .' | 830 | '------' | | |Tracker| '-----' | 831 | Peer Protocol/| | +-------+ | 832 | +------+ HTTP | | Tracker ^Protocol | 833 | |Mobile|<------------+ +---------+ | 834 | |Phone |<-------------------------+ | 835 | +------+ (Tracker Protocol) | 836 +-------------------------------------------------------------------+ 838 Figure 6 Serving Gateway/GGSN assisting P2P streaming delivery 840 7.6. Cache Service Supporting Streaming 842 Deploying cache nodes in the network edges can greatly decrease the 843 inter-network traffic and increase user experience in streaming 844 service. However, the cache nodes deployed by operators have to 845 execute DPI(deep packet inspection) and update their matching library 846 constantly to support more and more proprietary P2P streaming 847 protocols along with the increase of such applications. It increases 848 the operator's cost dramatically. 850 If PPSP were used in the cache nodes as well as the applications, 851 cache nodes can spend less cost to support more applications. 853 After the cache gets the content, it can reports to the P2P streaming 854 provider's tracker server just like as a normal peer and serves other 855 peers as shown in Figure 7. 857 +-------------------------------------------------------------------+ 858 | | 859 | Tracker Protocol +---------+ Tracker Protocol | 860 | +-------------> | Tracker |<--------------------+ | 861 | | +---------+ | | 862 | | | | 863 | | | | 864 | | | | 865 | V V | 866 | +-----------+ Peer Protocol +------------+ | 867 | | Cache |<---------------------------->| Peer | | 868 | +-----------+ +------------+ | 869 +-------------------------------------------------------------------+ 871 Figure 7 Cache Service Supporting Streaming 873 8. Security Considerations 875 PPSP has similar assumptions regarding peer privacy as P2PSIP 876 [ID.ietf-p2psip-base];that is, all participants in the system are 877 issued unique identities and credentials through some mechanism not 878 in the scope of PPSP. One possibility is a centralized server. Hence 879 PPSP will not attempt a solution to these issues for P2P streaming in 880 general. However PPSP has some unique security issues: 882 1) The content published by peers may not be checked by a centralized 883 certificating server. Consequently, P2P streaming may conduct 884 malicious content distribution. 886 2) Content pollution is another common problem faced by P2P streaming. 888 3) Because we focus on P2P streaming with a tracker who is critical 889 to the P2P streaming system, there may be a higher probability that 890 attacks are launched against the tracker. 892 PPSP may include some mechanisms to prevent malicious nodes from 893 polluting the streaming content or launching attacks on the tracker. 894 The protocol documents will contain a complete description on the 895 security/privacy concerns of PPSP. 897 9. Acknowledgments 899 We would like to acknowledge the following people who provided 900 feedback and suggestions to this document: D. Bryan from Cogent Force; 901 E. Marocco from Telecom Italia; V. Gurbani from Bell Labs/ /Alcatel- 902 Lucent; R. Even from Huawei; H. Zhang from NEC Labs, USA; C. Schmidt 903 and L. Xiao from NSN; C. Williams from ZTE; V. Pasual from Tekelec; D. 904 Zhang from PPlive; H. Deng from China Mobile; and J. Lei from Univ. 905 of Goettingen. 907 10. Informative References 909 [Cisco] Approaching the Zettabyte Era by Cisco. 911 [PPLive] www.pplive.com 913 [PPStream] www.ppstream.com 915 [UUSee] http://newteevee.com/2008/09/14/p2p-is-coming-to-youtube/ 917 [youtube] www.youtube.com 919 [tudou] www.tudou.com 921 [CNN] www.cnn.com 923 [Octoshape] www.octoshape.com 925 [ATT]http://mobile.sooyuu.com/Article/content/200905/217315094629281_ 926 1.shtml 928 [Sigcomm:P2P streaming]Challenges, Design and Analysis of a Large- 929 scale P2P-VoD System,Yan Huang et al, Sigcomm08. 931 [RFC 5693], Application-Layer Traffic Optimization (ALTO) Problem 932 Statement, E. Marocco et al, draft-ietf-alto-problem-statement-04 934 [Pando]www.pando.com 936 [CoolStreaming] CoolStreaming/DONet: A Data-Driven Overlay Network 937 for Efficient Live Media Streaming, Xinyan Zhang et al, 939 [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen 940 et al, 942 [draft-zhang-ppsp-protocol-comparison-measurement- 943 00]www.ietf.org/internet-drafts/draft-zhang-ppsp-protocol-comparison- 944 measurement-00.txt 946 [GENI] www.geni.net 948 [FIND]www.nets-find.net 950 [draft-zhang-ppsp-dsn-introduction-00]www.ietf.org/internet- 951 draft/draft-zhang-ppsp-dsn-introduction-00.txt 953 [MobileTV] MobileTV,Turning in or switching off, Arthur D. Little 955 [Computer Networks: Traffic] Traffic analysis of peer-to-peer IPTV 956 communities, Thomas Silverston et al, Computer Networks, 53 (2009) 957 470-484 959 [Survey]A survey on peer-to-peer video streaming systems Yong Liu et 960 al, Peer-to-Peer Netw Appl (2008) 1:18-28,Springer. 962 [draft-zhang-alto-traceroute-00] www.ietf.org/internet-draft/draft- 963 zhang-alto-traceroute-00.txt 965 [P2PStreamingSurvey] Zong, N. and X. Jiang, "Survey of P2P Streaming", 966 IETF PPSP BoF, November 2008. 968 [Challenge] Peer-to-Peer Live Video Streaming on the Internet: Issues, 969 Existing Approaches, and Challenges, Bo Li et al, IEEE Communications 970 Magazine, June 2007(94-99). 972 [CDN+P2P]Efficient Large-scale Content Distribution with Combination 973 of CDN and P2P Networks,Hai Jiang et al,International Journal of 974 Hybrid Information Technology, Vol.2, No.2, April, 2009. 976 [Peering CDN] A Case for Peering of Content Delivery Networks, 977 Rajkumar Buyya1 et al, 978 http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3d9924a 979 eb0dcd82ccc6716bbe36ec/index.jsp?&pName=dso_level1&path=dsonline/2006 980 /10&file=o10003.xml&xsl=article.xsl&. 982 [P2broadcast] P2broadcast: a hierarchical clustering live video 983 streaming system for P2P networks, De-kai Liu et al,International 984 Journal of Communication Systems,Volume 19,Issue 6. 986 [Hybrid]Hybrid Overlay Networks Management for Real-Time Multimedia 987 Streaming over P2P Networks, Mubashar Mushtaq et al, Lecture Notes in 988 Computer Science, Volume 4787/2007. 990 [AHLSS]AHLSS: A Hierarchical, Adaptive, Extendable P2P Live Streaming 991 System, Runzhi Li et al, International Journal of Distributed Sensor 992 Networks, Volume 5, Issue 1 January 2009. 994 [ComCast]http://www.afterdawn.com/news/article.cfm/2008/05/20/comcast 995 _invests_in_p2p_streaming_startup 997 [Johan Pouwelse]http://newteevee.com/2008/07/24/open-source-p2p- 998 streaming-getting-ready-to-disrupt-cdn-business-models/ 1000 [CNTV] news.xinhuanet.com/2010-06/30/c_12281703.htm 1002 [CNNIC] http://it.sohu.com/s2010/cnnic25/ 1004 [ID.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, 1005 S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)Base 1006 Protocol", draft-ietf-p2psip-base-08. 1008 [Akamai] Cheng Huang , Angela Wang , Jin Li , Keith W. Ross, 1009 Understanding hybrid CDN-P2P: why limelight needs its own Red Swoosh, 1010 Proceedings of the 18th International Workshop on Network and 1011 Operating Systems Support for Digital Audio and Video, May 28-30, 1012 2008, Braunschweig, Germany . 1014 Author's Addresses 1016 Yunfei Zhang 1018 China Mobile Communication Corporation 1020 zhangyunfei@chinamobile.com 1022 Ning Zong 1024 Huawei Technologies Co., Ltd. 1026 zongning@huawei.com 1028 Gonzalo Camarillo 1030 Ericsson 1032 Gonzalo.Camarillo@ericsson.com 1034 James Seng 1036 PPLive 1037 james.seng@pplive.com 1039 Richard Yang 1041 Yale University 1043 yry@cs.yale.edu