idnits 2.17.1 draft-zhang-ppsp-problem-statement-06.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 17 instances of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2010) is 5037 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 119, but not defined == Missing Reference: 'ComCast' is mentioned on line 143, but not defined == Missing Reference: 'P2PStreamSurvey' is mentioned on line 156, but not defined == Missing Reference: 'Survey' is mentioned on line 256, but not defined == Missing Reference: 'HTPT' is mentioned on line 367, but not defined == Missing Reference: 'FIND' is mentioned on line 422, but not defined == Missing Reference: 'Hybrid' is mentioned on line 745, but not defined == Missing Reference: 'AHLSS' is mentioned on line 746, but not defined == Unused Reference: 'PPStream' is defined on line 847, but no explicit reference was found in the text == Unused Reference: 'Octoshape' is defined on line 857, but no explicit reference was found in the text == Unused Reference: 'CoolStreaming' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'HPTP' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'Challenge' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'Peering CDN' is defined on line 912, but no explicit reference was found in the text == Unused Reference: 'ID.ietf-p2psip-base' is defined on line 941, 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 (~~), 17 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: Feb 2011 July 12, 2010 13 Problem Statement of P2P Streaming Protocol (PPSP) 14 draft-zhang-ppsp-problem-statement-06.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 to IETF 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), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on February 2,2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ................................................ 4 63 1.1. Background ............................................. 4 64 1.2. Research or Engineering................................. 5 65 1.3. Objective and outline................................... 5 66 2. Terminology and concepts..................................... 6 67 3. Introduction of P2P streaming system ........................ 8 68 4. Problem of proprietary protocols and incentives for developing 69 standard PPSP .................................................. 9 70 4.1. Proprietary signaling leads to difficult interactions in case 71 of multiple parties involved in the delivery ................ 10 72 4.2. Proprietary signaling leads to multiple client software in a 73 terminal .................................................... 11 74 4.3. Proprietary signaling leads to low network resource 75 utilization ................................................. 11 76 4.4. Proprietary signaling doesn't handle well with mobile and 77 wireless environment......................................... 11 78 5. Components of P2P streaming system........................... 13 79 6. Scope of PPSP ............................................... 14 80 6.1. Protocols to be standardized............................ 14 81 6.2. Service types to be considered ......................... 15 82 7. Use cases of PPSP ........................................... 16 83 7.1. Worldwide Provision by cooperative P2P Streaming vendors with 84 PPSP ........................................................ 16 85 7.2. Three Screen P2P streaming in heterogeneous environment using 86 PPSP......................................................... 17 87 7.3. CDN supporting streaming.................................18 88 7.4. Hierarchical P2P Streaming Distribution with PPSP .......19 89 7.5. Serving Gatwway/GGSN acting as Super Nodes assisting P2P 90 streaming delivery in Cellular mobile environment.............20 91 8. Security Considerations.......................................21 92 9. Acknowledgments ..............................................22 93 10. Informative References.......................................22 95 1. Introduction 97 1.1. Background 99 Streaming traffic is among the fastest growing traffic on the 100 Internet. In a recent white paper, Cisco predicts that by 2012, 90% 101 of all Internet traffic will be video [Cisco]. 103 There are two basic architectures for delivering streaming traffic on 104 the global Internet: the client-server paradigm and the peer to peer 105 (P2P) paradigm [P2PStreamingSurvey]. A particular advantage of the 106 P2P paradigm over the client-server paradigm is its scalability. As 107 an example, PPLive [PPLive], one of the largest P2P streaming vendors, 108 is able to distribute large-scale, live streaming programs such as 109 the CCTV Spring Festival Gala to more than 2 million users with only 110 a handful of servers. CNN[CNN] reported that P2P streaming by 111 Octoshape played a major role in its distribution of the historical 112 inauguration address of President Obama. It is well demonstrated in 113 practice that P2P streaming can deliver videos encoded at a rate of 114 about 400 Kbps, in the presence of rapid user joins/leaves, with 115 positive user experiences. 117 With the preceding technical advantages, P2P streaming is seeing 118 rapid deployment. Large P2P streaming applications such as PPLive 119 [PPLive], PPstream [PPstream] and UUSee [UUSee] each has a user base 120 exceeding 100 millions. P2P streaming traffic is becoming a major 121 type of Internet traffic in some Internet networks. For example, 122 according to the statistics of a major Chinese ISP, the traffic 123 generated by P2P streaming applications exceeded 50% of the total 124 backbone traffic during peak time in 2008. In the beginning of 2010, 125 CNTV, China National Network Television for CCTV launched its 126 software named CBox supporting P2P live and VoD programs. To date, it 127 has a rapid user increase. With the opening of FIFA world cup, CBox 128 has increased 5 times in user number with 3 million online users a 129 day and altogether 350 million times view. It is reported that CNTV 130 can support 10 million simultaneous user visit[CNTV]. Similarly there 131 were also reports that major video distributors such as Youtube 132 [youtube] and tudou [tudou] are conducting trials of using P2P 133 streaming as a component of their delivery infrastructures. 135 Given the increasing integration of P2P streaming into the global 136 content delivery infrastructure, the lacking of an open, standard P2P 137 streaming protocol becomes a major missing component in the Internet 138 protocol stack. Multiple, similar but proprietary P2P streaming 139 protocols result in repetitious development efforts and lock-in 140 effects. More importantly, we notice that more participants beyond 141 P2P streaming vendors have involved in P2P streaming industry, like 142 infrastructure vendors Akamai[Akamai], ChinaCache and ISP like 143 ComCast[ComCast]. That is, P2P streaming has become an open industry 144 with different participants from the source, infrastructure (in P2P 145 mode although all the peers are super nodes)delivery and local P2P 146 distribution to the terminals. 148 We argue that proprietary P2P streaming protocols lead to substantial 149 difficulties when integrating P2P streaming as an integral component 150 of a global content delivery infrastructure. For example, proprietary 151 P2P streaming protocols do not integrate well with existing cache and 152 other edge infrastructures. 154 1.2. Research or Engineering 156 As [P2PStreamSurvey] identifies, there exist multiple proprietary P2P 157 streaming systems including PPLive, PPstream, UUsee, Pando, abacast, 158 and Coolstreaming. A natural question to ask is whether the 159 development of P2P streaming is mature and ready for standardization. 160 We admit that P2P streaming will continue to improve and evolve. 161 However, our investigation shows that existing P2P streaming systems 162 are largely converging, sharing similar architecture and signaling 163 protocols [draft-zhang-ppsp-protocol-comparison-measurement-00]. 165 The aim of standardization in P2P streaming systems is to 1) decouple 166 the information exchange with the following delivery so that the most 167 common part in P2P streaming can use a generic and open protocol; 169 2) standardize the information exchange message so that equipments 170 from different providers can interact with each other for a complete 171 P2P streaming system. 173 1.3. Objective and outline 175 Multiple protocols such as streaming control, resource discovery, 176 streaming data transport, etc. are needed to build a P2P streaming 177 system [P2PStreamingSurvey]. We call those protocols P2P streaming 178 protocols. 180 The objective of the PPSP work is to standardize the key signaling 181 protocols among various P2P streaming system components including the 182 tracker and the peers. These protocols, called PPSP, are a part of 183 P2P streaming protocols. Note that the complete set of standard P2P 184 streaming protocols for a whole P2P streaming system could be 185 developed following or parallel to the PPSP work. 187 - PPSP will serve as an enabling technology, building on the 188 development experiences of existing P2P streaming systems. Its 189 design will allow it to integrate with IETF protocols on 190 distributed resource location, traffic localization, and streaming 191 control and data transfer mechanisms. Regarding to the components 192 it involves, PPSP allows effective integration between the peer 193 index server named tracker and different kinds of peers including 194 edge infrastructure nodes such as cache, gateway and CDN nodes who 195 can act as super peers and ordinary peers. 197 This document describes the terminologies, concepts and common 198 architecture for P2P streaming systems, problems without standardized 199 PPSP/incentives to standardize PPSP, scope of PPSP as well as its use 200 cases. The rest of this document is organized as follows. In Section 201 2, we introduce some common terminologies and concepts. In Section 3, 202 we introduce P2P streaming system architecture. In Section 4, we 203 identify the problems without standardized protocols and incentives 204 for developing PPSP protocols. In Section 5 and 6, we describe the 205 software architecture and functional components of P2P streaming 206 systems and therefore discuss the position and scope of PPSP. In 207 Section 7, we list some PPSP use cases. 209 2. Terminology and concepts 211 Chunk: A chunk is a basic unit of partitioned streaming, which is 212 used by a peer for the purpose of storage, advertisement and exchange 213 among peers [Sigcomm:P2P streaming]. 215 Content Distribution Network (CDN) node: A CDN node refers to a 216 network entity that usually is deployed at the network edge to store 217 content provided by the original servers, and serves content to the 218 clients located nearby topologically. 220 Live streaming: The scenario where all clients receive streaming 221 content for the same ongoing event. The lags between the play points 222 of the clients and that of the streaming source are small. 224 P2P cache: A P2P cache refers to a network entity that caches P2P 225 traffic in the network, and either transparently or explicitly as a 226 peer distributes content to other peers. 228 P2P streaming protocols: P2P streaming protocols refer to multiple 229 protocols such as streaming control, resource discovery, streaming 230 data transport, etc. which are needed to build a P2P streaming system. 232 Peer/PPSP peer: A peer/PPSP peer refers to a participant in a P2P 233 streaming system. The participant not only receives streaming content, 234 but also stores and uploads streaming content to other participants. 236 PPSP: PPSP refer to the key signaling protocols among various P2P 237 streaming system components including the tracker and peer. PPSP are 238 a part of P2P streaming protocols. 240 Swarm: A swarm refers to a group of clients (i.e. peers) sharing the 241 same content (e.g. video/audio program, digital file, etc) at a given 242 time. 244 Tracker/PPSP tracker: A tracker/PPSP tracker refers to a directory 245 service which maintains lists of peers/PPSP peers storing chunks for 246 a specific channel or streaming file and answers queries from 247 peers/PPSP peers for peer lists. 249 Video-on-demand (VoD): The scenario where different clients watch 250 different parts of the media recorded and stored during past events. 252 3. Introduction of P2P streaming system 254 There are multiple available P2P streaming solutions. Some are 255 deployed solutions, while others are still under active study. A 256 survey of existing solutions can be found in [Survey]. 258 In P2P streaming system, there are various swarms with each swarm 259 containing a group of clients sharing same streaming content (e.g. 260 channel, streaming file, etc) at a given time. These clients are 261 called peers, as each client not only receives streaming content, but 262 also stores and uploads streaming content to other clients. In a 263 broad sense of global content delivery infrastructure, peers can 264 include multiple types of entities such as end user applications, 265 caches, CDN nodes, and/or other edge devices. Therefore, the basic 266 functions of a P2P streaming system involve: 268 1) Maintaining information about which peers in which swarm in some 269 directory service, a.k.a. tracker. 271 2) In each swarm, exchange information about content availability 272 (e.g. which chunks stored by a peer) among peers, or between 273 tracker and peer. 275 3) In each swarm, exchange the actual content among peers. 277 As shown in Figure 1, common information flows in a P2P streaming 278 system include: 280 1) When a peer wants to receive streaming content: 282 1.1) Peer acquires a list of peers in the swarm from the tracker. A 283 swarm can be indexed by a channel ID, streaming file ID, etc. 285 1.2) Peer exchanges its content availability with the peers on the 286 obtained peer list. 288 1.3) Peer identifies the peers with desired content and requests for 289 the content from the identified peers. 291 2) When a peer wants to share streaming content with others: 293 2.1) Peer sends information to the tracker about the swarms it 294 belongs to, plus streaming status and/or content availability. 296 +-------------------------------------------------------+ 297 | +-------------------+ | 298 | | Tracker | | 299 | +-------------------+ | 300 | ^ | ^ | 301 | | | |swarms, | 302 | query | | peer list |streaming status | 303 | | | |and/or content | 304 | | | |availability | 305 | | V | | 306 | +-------------+ +------------+ | 307 | | Peer1 |<------->| Peer 2 | | 308 | +-------------+ content +------------+ | 309 | ^ ^ availability | 310 | * | content | 311 | content * |availability | 312 | * V | 313 | +------------+ | 314 | | Peer 3 | | 315 | +------------+ | 316 +-------------------------------------------------------+ 317 Figure 1 Common information flows in P2P streaming system 319 4. Problem of proprietary protocols and incentives for developing 320 standard PPSP 322 We start by considering the success of the Web. It is the standard 323 HTTP protocol that makes it possible to deploy the global content 324 distribution eco-system that consists of not only end devices such as 325 Web servers and Web clients, but also infrastructure devices such as 326 Web caches and CDN nodes. All of these devices communicate through 327 standard protocols and provide substantial benefits to the consumers, 328 the content publishers, and the network infrastructure. 330 As we discussed in Section 1, given the increasing integration of P2P 331 streaming into the global content delivery infrastructure, 332 proprietary P2P streaming protocols not only result in repetitious 333 development efforts and lock-in effect, but also leads to substantial 334 difficulties when integrating P2P streaming as an integral component 335 of a global content delivery infrastructure. The explicit incentives 336 to get rid of the proprietary protocols can be seen from the talks of 337 Johan Pouwelse, scientific director of P2P Next: "?broadcasters from 338 the BBC to Germany's ARD just seem to love the idea of ditching their 339 proprietary platforms[Johan Pouwelse]." 340 Let's take a look of several cases for further problem identification. 342 4.1. Proprietary signaling leads to difficult interactions in case 343 of multiple parties involved in the delivery 345 Let's first see a simplest case.In an open P2P streaming industrial 346 environment, it's a common thing for different streaming vendors(esp. 347 spread in different regions) cooperatively take the broadcasting. 348 Suppose PPLive broadcasts live Chinese spring festival gala for 349 American Chinese by Pando networks. At a first sight, this seems 350 reasonable because there are relatively few American Chinese PPLive 351 users. Therefore it's hard to realize efficient P2P delivery by 352 PPLive network only. Borrowing peer resources from an ally like 353 Pando may help the efficient distribution. However different messages 354 and interactions in the two systems cause the difficulty in 355 interoperability among PPLive peers and Pando peers. 357 Consider a more complex case where P2P streaming vendors cooperate 358 with CDN providers. People can refer to UUSee, RayV and Forthtech 359 practice for this use case. In the context of P2P streaming, 360 infrastructure devices such as edge caches and CDN nodes have been 361 shown as promising means to both improve the performance of P2P 362 streaming (e.g., lower latency) by providing more stable "super 363 peers" and reduce traffic in ISP network [CDN+P2P] [RFC 5693]. 365 However, there can be substantial obstacles in deploying 366 infrastructure edge devices supporting proprietary P2P streaming 367 protocols [HTPT]. Unlike the Web with the standard HTTP protocol, the 368 current P2P streaming landscape consists of multiple, proprietary P2P 369 streaming protocols mostly differing in signaling transactions. 370 Consequently, in order to support P2P streaming, the infrastructure 371 devices need to understand and keep updated with various proprietary 372 P2P streaming protocols. This introduces complexity and deployment 373 cost of infrastructure devices. 375 Things get worse if there are M P2P streaming vendors and N CDN 376 providers for possible cooperative combination. How does a specific 377 CDN node identify different private systems and report to different 378 trackers with proprietary protocols? It seems there are no good ways 379 to address this. The CDN node has to update its protocol through 380 case-by-case negotiations. 382 With standard PPSP, edge caches and CDN nodes can be designed to 383 inter-operate with only the standard protocols, reducing the 384 complexity and cost to support streaming involving P2P. 386 4.2. Proprietary signaling leads to multiple client software in a 387 terminal 389 Because of the private protocols, although there are quite much in 390 common, application developers cannot reuse the common parts, wasting 391 a lot of repeated work. 393 This makes a terminal installing multiple different software for 394 different purpose. For example a user installs CBox for CCTV program 395 watching and PPLive for Japanese and Korean movies. This brings two 396 problems: 398 1) Terminal limitation may don't allow for many clients in one 399 machine, esp. for mobile terminals. The limited CPU,storage and cache 400 often limit the concurrent threads and processes. 402 2) Because different software are independent, it may lead to vicious 403 competitions. We even see the competitors to delete each other's 404 software when automatically running the software. If there are 405 standard protocols and some common part to co-use, such things are 406 hard to occur. 408 4.3. Proprietary signaling leads to low network resource utilization 410 From the network resource utilization perspective, if we have no 411 standard protocols in designating the resource availability( which is 412 the imagined PPSP task)and every application uses proprietary 413 protocol for storage and bandwidth usage, then for a same content, 414 many on-the-way data in different applications have to be 415 cached/stored and transferred repeatedly, which wastes storage and 416 causes possible congestion in the network. 418 4.4. Proprietary signaling doesn't handle well with mobile and 419 wireless environment 421 Mobility and wireless are becoming increasingly important features to 422 support in future Internet deployments [GENI], [FIND]. Currently 423 there are more and more mobile and wireless Internet users. By the 424 end of 2009, there are 233 million mobile users in China[CNNIC]. 426 Along with the introduction of mobile and wireless capabilities into 427 the Internet, mobile streaming is becoming a key offered service 428 [MobileTV]. In Korea the number of mobile TV subscriber has reached 429 seventeen millions, accounting for one third of the mobile 430 subscribers. In Italy, there are one million mobile TV users. During 431 the 2008 Beijing Olympic Games, more than one million users utilize 432 China mobile's mobile TV service. 434 Considering the mobile and wireless nodes have better CPU, memory and 435 storage and the mobile network has better network bandwidth (esp. 436 there are more uplink bandwidth which is wasted for transferring 437 little data in current practice) than before, there are much more 438 possibility for the mobile and wireless node to be peers supporting 439 P2P streaming. 441 However, mobile peers may face bigger challenges for supporting P2P 442 streaming with unsteady network connections, less steady power and 443 different media coding for mobile devices. Current proprietary 444 protocols are mainly designed in fixed Internet environment and don't 445 address these challenges. We may therefore raise such a question: 446 Shall we let these private protocols to fit in mobile environment 447 system-by-system independently or solve these problems in the design 448 of an open PPSP protocol suite? 450 The answer is obviously clear. It is worth mentioning that the 451 development of PPSP should consider the specific requirements of 452 mobile Internet. For example, the overhead of PPSP be small in low 453 bandwidth mobile Internet. Also, information exchange in PPSP should 454 support mobility, low battery and heterogeneous capabilities of 455 mobile terminals. Systematic requirements on the development of PPSP 456 will be addressed in the requirements documents. 458 5. Components of P2P streaming system 460 +---------------------------------------------------+ 461 | Application Layer | 462 |---------------------------------------------------| 463 | Play-out Layer | 464 | +----------+ +------------+ +-----------+ | 465 | |start/stop| |pause/resume| | FF/rewind | | 466 | +----------+ +------------+ +-----------+ | 467 |-------------------------------------------------- | 468 | Information Layer | 469 | +------------+ +------+ +-----------+ | 470 | |registration| |report| | statistics| | 471 | +------------+ +------+ +-----------+ | 472 |---------------------------------------------------| 473 | Communication Layer | 474 | +---------------------+ +------------------+ | 475 | |tracker communication| |peer communication| | 476 | +---------------------+ +------------------+ | 477 | +-------------+ | 478 | | bootstrap | | 479 | +-------------+ | 480 |---------------------------------------------------| 481 | Transport Layer | 482 +---------------------------------------------------+ 483 Figure 2 Components of P2P streaming system 485 To organize our efforts, we show the components of a complete P2P 486 streaming system in Figure 2. 488 1) Transport Layer is responsible for data transmission between peers. 489 UDP, TCP or other protocols can be used. 491 2) Communication layer includes three components: 493 2.1) Tracker communication is a component that enables each peer to 494 get peer list from the tracker and/or provide content availability to 495 the tracker. 497 2.2) Peer communication is a component that enables each peer to 498 exchange content availability and request other peers for content. 500 2.3) Bootstrap is a component that enables newly joined nodes to 501 obtain tracker information. 503 3) Information layer is responsible for peer and content information 504 collection and management. 506 3.1) Registration is a component that enables nodes to register to 507 the system, and publish the content information. The information may 508 include but is not limited to: content description, content type, 509 creation time, node information such as physical location, IP address. 511 3.2) Report is a component that enables peers to report streaming 512 status to the tracker. The information may include peer 513 inbound/outbound traffic, amount of neighbor peers, peer health 514 degree and other streaming parameters. 516 3.3) Statistics is a component that enables trackers to manage the 517 aggregated system information for global control in upload bandwidth 518 consumption, overhead consumption and other regards. 520 4) Play-out layer is responsible for controlling the action of media 521 play (e.g. start, pause, resume, stop, fast-forward, and rewind). 523 5) Application layer is the top layer for streaming applications. 525 6. Scope of PPSP 527 6.1. Protocols to be standardized 529 We propose to standardize protocols in PPSP which enable the tracker 530 communication and the peer communication components in the 531 communication layer, as well as the report component in the 532 information layer. These protocols, called PPSP, are key mechanisms 533 involving two important roles - tracker and peer in P2P streaming 534 processes, as addressed in Section 3. These signaling protocols,in 535 essence, aim at standardizing the content information exchange 536 mechanisms among different devices in P2P streaming systems. Note 537 that PPSP are only a part of P2P streaming protocols. The complete 538 set of standard P2P streaming protocols for a whole P2P streaming 539 system could be developed following or parallel to the PPSP work. 541 Because bootstrap, registration and statistics components are out-of- 542 band mechanisms for streaming processes, they are not in current 543 scope of PPSP. Both transport, play-out and application layers in P2P 544 streaming system are also beyond the current scope of PPSP. 546 Therefore, PPSP include the PPSP tracker protocol - a signaling 547 protocol between PPSP trackers and PPSP peers, and the PPSP peer 548 protocol - a signaling protocol among PPSP peers. 550 1) PPSP tracker protocol 552 This protocol will define: 554 1.1) Standard format/encoding of information between PPSP peers and 555 PPSP trackers, such as peer list, content availability, streaming 556 status including online time, link status, node capability and other 557 streaming parameters. 559 1.2) Standard messages between PPSP peers and PPSP trackers defining 560 how PPSP peers report streaming status and request to PPSP trackers, 561 as well as how PPSP trackers reply to the requests. 563 Note that existing protocols should be investigated and evaluated for 564 being reused or extended as the messages between tracker and peer. 565 Possible candidates include the use of the HTTP, where the GET method 566 could be used to obtain peer lists, the POST method used for 567 streaming status reports, etc. 569 2) PPSP peer protocol 571 This protocol will define: 573 2.1) Standard format/encoding of information among PPSP peers, such 574 as chunk description. 576 2.2) Standard messages among PPSP peers defining how PPSP peers 577 advertise chunk availability to each other, as well as the signaling 578 for requesting the chunks among PPSP peers. 580 Again, existing protocols should be investigated and evaluated for 581 being reused or extended as the messages among peers. Possible 582 candidates include the use of the HTTP, where the GET method could be 583 used to obtain chunk availability, etc. Considering the potential 584 large number of peers, some lightweight (possibly binary) protocols 585 could also be good candidates. 587 6.2. Service types to be considered 589 As stated in Section 1, PPSP will serve as enabling technology and 590 tools for building various P2P streaming systems. We are not 591 standardizing certain streaming services. The reason why we list 592 service types here is to show we would consider the properties of 593 these services as the requirements for PPSP design. 595 Common service types supported by current P2P streaming systems 596 include live streaming(including time-shift), video-on-demand (VoD). 598 In live streaming, all PPSP peers are interested in the media coming 599 from an ongoing event, which means that all PPSP peers share nearly 600 the same streaming content at a given point of time. In live 601 streaming, some PPSP peers may store the live media for further 602 distribution, which is known as TSTV (time-shift TV) where the stored 603 media are separated into chunks and distributed in a VoD-like manner. 605 In VoD, different PPSP peers watch different parts of the media 606 recorded and stored during a past event. In this case, each PPSP peer 607 keeps asking other PPSP peers which media chunks are stored in which 608 PPSP peers, and then pulls the required media from some selected PPSP 609 peers. 611 7. Use cases of PPSP 613 7.1. Worldwide Provision by cooperative P2P Streaming vendors with 614 PPSP 616 As stated in section 4.1,the cooperation of P2P Streaming vendors can 617 easily expand the broadcasting scale with standard PPSP. The 618 interactions between cooperative P2P streaming provider A's tracker 619 server and P2P streaming provider B and C's SuperNodes is shown in 620 Figure 3. 622 +-------------------------------------------------------------------+ 623 | | 624 | +------------------+ | 625 | +------------>| A's Tracker |<----------+ | 626 | | +------------------+ | | 627 | Tracker| ^ ^ | | 628 | Protocol| Tracker| |Tracker |Tracker | 629 | | Protocol| |Protocol |Protocol | 630 | | | | | | 631 | | | | | | 632 | v v v v | 633 | +------+ Peer +------+ +------+ +------+ | 634 | | B's |<------->| B's | | C's | | C's | | 635 | | SN1 |Protocol | SN2 | | SN1 | | SN2 | | 636 | +------+ +------+ +------+ +------+ | 637 | ^ ^ ^ ^ | 638 | | | | | | 639 | | | Peer Protocol Peer Protocol| | | 640 | Peer | +-------------+ +-------------+ |Peer | 641 | Procotol| | | |protocol| 642 | | | | | | 643 | | | | | | 644 | | | | | | 645 | v v v v | 646 | +------+ Peer +------+ +---------+ Peer +---------+ | 647 | | A's |<------> | B's | |A's |<------> |C's | | 648 | | User1|Protocol | User2| | User1 |Protocol | User2 | | 649 | +------+ +------+ +---------+ +---------+ | 650 | | 651 +-------------------------------------------------------------------+ 652 Figure 3 Cooperative Vendors Interactions 654 7.2. Three Screen P2P streaming in heterogeneous environment using 655 PPSP 657 This is a use case where PC, Setbox/TV and mobile terminals from 658 fixed Internet, mobile Internet constitute the peer overlay for 659 streaming content sharing. Using PPSP protocols, peers from different 660 kinds of networks can share and download what they have from each 661 other to form a 3 screen streaming system. 663 +-------------------------------------------------------------------+ 664 | | 665 | Tracker Protocol +---------+ Tracker Protocol | 666 | +-------------> | Tracker |<------------------+ | 667 | | +---------+ | | 668 | | ^ | | 669 | | | | | 670 | | | | | 671 | V | V | 672 | +------+ | +------------+ | 673 | | STB | Tracker Protocol |Mobile Phone| | 674 | +------+ | +------------+ | 675 | ^ | ^ | 676 | | | | | 677 | | | | | 678 | | V | | 679 | |Peer Protocol +---------+ Peer Protocol | | 680 | +-------------> | PC |<------------------+ | 681 | +---------+ | 682 | | 683 +-------------------------------------------------------------------+ 684 Figure 4 Heterogeneous P2P Streaming Interactions with PPSP 686 7.3. CDN supporting streaming 688 This scenario is similar to use case 1 except that this is more like 689 a M to N mapping while use case 1 is more often to be a case by case 690 mapping. This reduces the case by case negotiation between the 691 original provider and multiple CDN providers if otherwise proprietary 692 protocols are used makes it easier for both sides to interoperate. 694 The interactions between the P2P streaming provider's tracker server 695 and CDN surrogates as well as interactions between CDN surrogates are 696 the same as a normal peer as shown in Figure 4. 698 PPSP can be used in: 700 1) Interface between CDN nodes and tracker. This is very useful for a 701 small streaming provider who has no its own CDN surrogates and much 702 money to distribute its stream worldwide. 704 2) New construction of CDN systems by PPSP. This can often occur for 705 an operator or CDN vendor to build a P2P CDN system supporting 706 streaming or file sharing applications with low cost. 708 +-------------------------------------------------------------------+ 709 | | 710 | +------------------+ | 711 | +------------>| Original Tracker |<----------+ | 712 | | +------------------+ | | 713 | Tracker| ^ ^ | | 714 | Protocol| Tracker| |Tracker |Tracker | 715 | | Protocol| |Protocol |Protocol | 716 | | | | | | 717 | | | | | | 718 | v v v v | 719 | +------+ Peer +------+ +------+ +------+ | 720 | | CDN1 |<------->| CDN1 | | CDN2 | | CND2 | | 721 | | POP2 |Protocol | POP1 | | POP1 | | POP2 | | 722 | +------+ +------+ +------+ +------+ | 723 | ^ ^ ^ ^ | 724 | | | | | | 725 | | | Peer Protocol Peer Protocol| | | 726 | Peer | +-------------+ +--------------+ |Peer | 727 | Procotol| | | |protocol| 728 | | | | | | 729 | | | | | | 730 | | | | | | 731 | v v v v | 732 | +------+ Peer +------+ +---------+ Peer +---------+ | 733 | | USA |<------> | USA | |Caribbean|<------> |Caribbean| | 734 | | User1|Protocol | User2| | User1 |Protocol | User2 | | 735 | +------+ +------+ +---------+ +---------+ | 736 | | 737 +-------------------------------------------------------------------+ 738 Figure 5 CDN Supporting P2P Streaming with PPSP 740 7.4. Hierarchical P2P Streaming Distribution with PPSP 742 The hierarchical P2P streaming distribution have many advantages over 743 non-hierarchical conterparters such as better QoS(start-up latency 744 and service interruption reduction[P2broadcast], higher throughput 745 and lower packets drop ratio[Hybrid], topology-mismatch reduction and 746 better management[AHLSS]. 748 PPSP is useful for clustering the peers because there are abundant 749 node information and content information exchange fetched in the 750 message. 752 7.5. Serving Gateway/GGSN acting as Super Nodes assisting 753 P2P streaming delivery in Cellular mobile environment 755 In cellular mobile environment, with the increase in bandwidth and 756 mobile terminal capabilities, P2P streaming is better to be realized 757 than before. Note that we don't have compulsory mobile peers. The 758 network peers and WIFI peers are easier selected. GGSN, as the 759 gateway for the cellular network to Internet, is more and more viewed 760 as a promising place to add the cache functionality assisting P2P 761 streaming services. Because it's deployed by the operators, the 762 stability and storage size are better guaranteed than ordinary PC. 763 It's more likely to select GGSN as the super nodes assisting the 764 delivery. The interactions between serving gateway/GGSN and tracker, between 765 different serving gateways/GGSNs and between serving gateway/GGSN and mobile 766 terminal is explicated in Fig6.We name these kinds of serving gateway/GGSN as 767 Mobile Supporting Super Nodes(MSSN).Note that if mobile terminals are not eligible 768 to be a peer, it can use client/server mode for streaming service simply taking 769 serving gateway/GGSN a source. 771 There are basically two scenarios in cellular networks: 773 1) Self operational P2P streaming services for mobile operators: PPSP 774 is the suitable protocol for tracker-serving gateway/GGSN and serving 775 gateway/GGSN-mobile nodes interaction. The serving gateway/GGSN can be 776 both a super node or a complete proxy for different mobile terminals with 777 different capabilities. 779 2) The 3rd party P2P streaming service with optimized localization by 780 GGSN. When introducing a popular P2P streaming application like 781 PPLive in the mobile network, serving gateway/GGSN can coordinate with the 3rd party 782 trackers to cache the content without needing continuous update of 783 the 3rd party protocols. 785 +-------------------------------------------------------------------+ 786 | | 787 | Peer Protocol | 788 | +--------------------+ | 789 | | | | 790 | ,--...- | ,--...- | ,--...- | 791 | .' '. | .' '. | .' '. | 792 | / \ V / \ V / \ | 793 | ' Cellular +------+ Internet +------+ Cellular | | 794 | | Access | MSSN | | MSSN | Access / | 795 | \ Network +------+ +------+ Networks / | 796 | \ /^ ^ \ / \ .' | 797 | `. / | | \ / \ .' | 798 | '. .' | | '+-------+' `. ./ | 799 | '------' | | |Tracker| `-------' | 800 | Peer Protocol | | +-------+ | 801 | +------+ /HTTP | | Tracker ^ Protocol | 802 | |Mobile|<------------+ +---------+ | 803 | |Phone |<-------------------------+ | 804 | +------+ (Tracker Protocol) | 805 +-------------------------------------------------------------------+ 806 Figure 6 GGSN assisting P2P streaming delivery 808 8. Security Considerations 810 PPSP has a similar assumption in peer privacy as P2PSIP[ID.ietf- 811 p2psip-base], i.e., all participants in the system are issued unique 812 identities and credentials through some mechanism not in the scope of 813 PPSP, such as a centralized server. Hence PPSP will not attempt a 814 solution to these issues for P2P streaming networks in general. 815 However PPSP have some unique security issues: 817 1) The content published by peers may not be checked by centralized 818 certificating server. Therefore P2P streaming network may have the 819 danger of malicious content distribution. 821 2) Content pollution is another common problem faced by P2P streaming. 823 3) Because there is a tracker who is critical to the P2P streaming 824 systems. There is an increased probability that threats may involve 825 launching attacks against the tracker. 827 PPSP may include some mechanisms to prevent malicious nodes from 828 polluting the streaming content or launch attacks to the tracker. The 829 protocol documents will contain a complete description of the 830 security/privacy concerns of PPSP. 832 9. Acknowledgments 834 We would like to acknowledge the following who provided feedback or 835 suggestions for this document: D. Bryan from Cogent Force; E. Marocco 836 from Telecom Italia; V. Gurbani from AT&T; R. Even from Huawei; H. 837 Zhang from NEC Labs, USA; C. Schmidt and L. Xiao from NSN; C. 838 Williams from ZTE; V. Pasual from Tekelec; X. Zhang from PPlive; H. 839 Deng from China Mobile; and J. Lei from Univ. of Goettingen. 841 10. Informative References 843 [Cisco] Approaching the Zettabyte Era by Cisco. 845 [PPLive] www.pplive.com 847 [PPStream] www.ppstream.com 849 [UUSee] www.uusee.com 851 [youtube] www.youtube.com 853 [tudou] www.tudou.com 855 [CNN] www.cnn.com 857 [Octoshape] www.octoshape.com 859 [ATT]http://mobile.sooyuu.com/Article/content/200905/2173150946 860 29281_1.shtml 862 [Sigcomm:P2P streaming]Challenges, Design and Analysis of a 863 Large-scale P2P-VoD System,Yan Huang et al, Sigcomm08. 865 [RFC 5693] Application-Layer Traffic Optimization (ALTO) 866 Problem Statement, E. Marocco et al, draft-ietf-alto-problem- 867 statement-04 869 [Pando]www.pando.com 871 [CoolStreaming] CoolStreaming/DONet: A Data-Driven Overlay 872 Network for Efficient Live Media Streaming, Xinyan Zhang et al, 874 [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin 875 Shen et al, 877 [draft-zhang-ppsp-protocol-comparison-measurement- 878 00]www.ietf.org/internet-drafts/draft-zhang-ppsp-protocol- 879 comparison-measurement-00.txt 881 [GENI] www.geni.net 883 [FIND]www.nets-find.net 885 [draft-zhang-ppsp-dsn-introduction-00]www.ietf.org/internet- 886 draft/draft-zhang-ppsp-dsn-introduction-00.txt 888 [MobileTV] MobileTV,Turning in or switching off, Arthur D. 889 Little 891 [Computer Networks: Traffic] Traffic analysis of peer-to-peer 892 IPTV communities, Thomas Silverston et al, Computer Networks, 893 53 (2009) 470-484 895 [Survey]A survey on peer-to-peer video streaming systems Yong 896 Liu et al, Peer-to-Peer Netw Appl (2008) 1:18-28,Springer. 898 [draft-zhang-alto-traceroute-00] www.ietf.org/internet- 899 draft/draft-zhang-alto-traceroute-00.txt 901 [P2PStreamingSurvey] Zong, N. and X. Jiang, "Survey of P2P 902 Streaming", IETF PPSP BoF, November 2008. 904 [Challenge] Peer-to-Peer Live Video Streaming on the Internet: 905 Issues, Existing Approaches, and Challenges, Bo Li et al, IEEE 906 Communications Magazine, June 2007(94-99). 908 [CDN+P2P]Efficient Large-scale Content Distribution with 909 Combination of CDN and P2P Networks,Hai Jiang et 910 al,International Journal of Hybrid Information Technology, 911 Vol.2, No.2, April, 2009. 912 [Peering CDN] A Case for Peering of Content Delivery Networks, 913 Rajkumar Buyya1 et al, 914 http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3 915 d9924aeb0dcd82ccc6716bbe36ec/index.jsp?&pName=dso_level1&path=d 916 sonline/2006/10&file=o10003.xml&xsl=article.xsl&. 918 [P2broadcast] P2broadcast: a hierarchical clustering live video 919 streaming system for P2P networks, De-kai Liu et 920 al,International Journal of Communication Systems,Volume 921 19,Issue 6. 923 [Hybrid]Hybrid Overlay Networks Management for Real-Time 924 Multimedia Streaming over P2P Networks, Mubashar Mushtaq et al, 925 Lecture Notes in Computer Science, Volume 4787/2007. 927 [AHLSS]AHLSS: A Hierarchical, Adaptive, Extendable P2P Live 928 Streaming System, Runzhi Li et al, International Journal of 929 Distributed Sensor Networks, Volume 5, Issue 1 January 2009. 931 [ComCast]http://www.afterdawn.com/news/article.cfm/2008/05/20/c 932 omcast_invests_in_p2p_streaming_startup 934 [Johan Pouwelse]http://newteevee.com/2008/07/24/open-source- 935 p2p-streaming-getting-ready-to-disrupt-cdn-business-models/ 937 [CNTV] news.xinhuanet.com/2010-06/30/c_12281703.htm 939 [CNNIC] http://it.sohu.com/s2010/cnnic25/ 941 [ID.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., 942 Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery 943 (RELOAD)Base Protocol", draft-ietf-p2psip-base-08. 945 [Akamai] Cheng Huang , Angela Wang , Jin Li , Keith W. Ross, 946 Understanding hybrid CDN-P2P: why limelight needs its own Red 947 Swoosh, Proceedings of the 18th International Workshop on 948 Network and Operating Systems Support for Digital Audio and 949 Video, May 28-30, 2008, Braunschweig, Germany . 951 Author's Addresses 953 Yunfei Zhang 955 China Mobile Communication Corporation 957 zhangyunfei@chinamobile.com 959 Ning Zong 961 Huawei Technologies Co., Ltd. 963 zongning@huawei.com 965 Gonzalo Camarillo 967 Ericsson 969 Gonzalo.Camarillo@ericsson.com 971 James Seng 973 PPLive 975 james.seng@pplive.com 977 Richard Yang 979 Yale University 981 yry@cs.yale.edu