idnits 2.17.1 draft-zhang-ppsp-problem-statement-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 is 1 instance of too long lines in the document, the longest one being 3 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 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 20, 2009) is 5301 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: 'HTPT' is mentioned on line 326, but not defined == Unused Reference: 'ID.ietf-p2psip-base' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'PPStream' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'Octoshape' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'ATT' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'Pando' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'CoolStreaming' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'HPTP' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'Challenge' is defined on line 747, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-02 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPSP Y. Zhang 3 Internet-Draft China Mobile 4 Intended status: Standards Track N. Zong 5 Expires: April 23, 2010 Huawei Technologies 6 G. Camarillo 7 Ericsson 8 J. Seng 9 PPLive 10 R. Yang 11 Yale University 12 October 20, 2009 14 Problem Statement of P2P Streaming Protocol (PPSP) 15 draft-zhang-ppsp-problem-statement-05 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may contain material 21 from IETF Documents or IETF Contributions published or made publicly 22 available before November 10, 2008. The person(s) controlling the 23 copyright in some of this material may not have granted the IETF 24 Trust the right to allow modifications of such material outside the 25 IETF Standards Process. Without obtaining an adequate license from 26 the person(s) controlling the copyright in such materials, this 27 document may not be modified outside the IETF Standards Process, and 28 derivative works of it may not be created outside the IETF Standards 29 Process, except to format it for publication as an RFC or to 30 translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on April 23, 2010. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents in effect on the date of 57 publication of this document (http://trustee.ietf.org/license-info). 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Abstract 63 We propose to standardize the key signaling protocols among various 64 P2P streaming system components including the tracker and the peers. 65 These protocols, called PPSP, are a part of P2P streaming protocols. 66 This document describes the terminologies, concepts, incentives, and 67 scope of developing PPSP, as well as the use cases of PPSP. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.2. Research or engineering . . . . . . . . . . . . . . . . . 5 74 1.3. Objective of the PPSP work . . . . . . . . . . . . . . . . 5 75 2. Terminology and concepts . . . . . . . . . . . . . . . . . . . 5 76 3. Introduction of P2P streaming system . . . . . . . . . . . . . 6 77 4. Incentives for developing standard PPSP . . . . . . . . . . . 8 78 4.1. P2P streaming and edge cache/CDN support . . . . . . . . . 9 79 4.2. Incentive for ISPs . . . . . . . . . . . . . . . . . . . . 9 80 5. Components of P2P streaming system . . . . . . . . . . . . . . 10 81 6. Scope of PPSP . . . . . . . . . . . . . . . . . . . . . . . . 11 82 6.1. Protocols to be standardized . . . . . . . . . . . . . . . 11 83 6.2. Service types to be considered . . . . . . . . . . . . . . 13 84 7. Use cases of PPSP . . . . . . . . . . . . . . . . . . . . . . 13 85 7.1. Worldwide Provision of P2P Streaming Service with PPSP . . 13 86 7.2. Hierarchical P2P Streaming Distribution with PPSP . . . . 15 87 7.3. Unified client software to watch P2P Streaming Programs . 15 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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 paradigms for delivering streaming traffic on the 104 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 108 vendors, is able to distribute large-scale, live streaming programs 109 such as the CCTV Spring Festival Gala to more than 2 million users 110 with only a handful of servers. CNN [CNN] reported that P2P 111 streaming by Octoshape played a major role in its distribution of the 112 historic inauguration address of President Obama. It is well 113 demonstrated in practice that P2P streaming can deliver videos 114 encoded at a rate of about 400 Kbps, in the presence of churn, with 115 positive user experiences. 117 In light of these technical advantages, P2P streaming is seeing rapid 118 deployment. Large P2P streaming applications such as PPLive 119 [PPLive], PPstream [PPstream] and UUSee [UUSee] have each reached a 120 number of installations exceeding 100 millions. P2P streaming 121 traffic is becoming a major type of Internet traffic in some Internet 122 networks. For example, according to the statistics of a major 123 Chinese ISP, the traffic generated by P2P streaming applications 124 exceeded 50% of the total backbone traffic during peak time in 2008. 125 There are reports that major video distributors such as Youtube 126 [youtube] and tudou [tudou] are conducting trials of using P2P 127 streaming as a component of their delivery infrastructures. 129 Given the increasing integration of P2P streaming into the global 130 content delivery infrastructure, the lack of open standard P2P 131 streaming protocol has become a major missing component in the 132 Internet protocol stack. Multiple similar but proprietary P2P 133 streaming protocols result in repetitious development efforts and 134 lock-in effects. More importantly, it leads to substantial 135 difficulties when integrating P2P streaming as a component of a 136 global content delivery infrastructure. For example, proprietary P2P 137 streaming protocols do not integrate well with infrastructure devices 138 such as caches and other edge devices. 140 1.2. Research or engineering 142 As [P2PStreamingSurvey] identifies, there exist multiple proprietary 143 P2P streaming systems including PPLive, PPstream, UUsee, abacast, and 144 Coolstreaming. A natural question to ask is whether the development 145 of P2P streaming is mature and ready for standardization. We admit 146 that P2P streaming will continue to improve and evolve. However, our 147 investigation shows that existing P2P streaming systems are largely 148 converging, sharing similar architecture and signaling protocols 149 [draft-zhang-ppsp-protocol-comparison-measurement-00]. The 150 competition of P2P streaming vendors is focusing increasingly on 151 content. 153 1.3. Objective of the PPSP work 155 Multiple protocols such as streaming control, resource discovery, 156 streaming data transport, etc. are needed to build a P2P streaming 157 system [P2PStreamingSurvey]. We call those protocols P2P streaming 158 protocols. 160 The objective of the PPSP work is to standardize the key signaling 161 protocols among various P2P streaming system components including the 162 tracker and the peers. These protocols, called PPSP, are a part of 163 P2P streaming protocols. Note that the complete set of standard P2P 164 streaming protocols for a whole P2P streaming system could be 165 developed following or parallel to the PPSP work. PPSP will serve as 166 an enabling technology, building on the development experiences of 167 existing P2P streaming systems. Its design will allow it to 168 integrate with IETF efforts on distributed resource location, traffic 169 localization, and streaming control mechanisms. It allows effective 170 integration with edge infrastructures such as cache and mobile edge 171 equipment. 173 This document describes the terminologies, concepts, incentives, and 174 scope of developing PPSP, as well as the use cases of PPSP. The rest 175 of this document is organized as follows. In Section 2, we introduce 176 some common terminologies and concepts. In Section 3, we introduce 177 P2P streaming system. In Section 4, we identify the incentives for 178 developing standard P2P streaming protocols. In Section 5, we 179 describe the components of P2P streaming system. In Section 6, we 180 outline the main scope of PPSP. In Section 7, we list some use cases 181 of PPSP. 183 2. Terminology and concepts 185 Chunk: A chunk is a basic unit of partitioned streaming, which is 186 used by a peer for the purpose of storage, advertisement and exchange 187 among peers [Sigcomm:P2P streaming]. 189 Content Distribution Network (CDN) node: A CDN node refers to a 190 network entity that usually is deployed at the network edge to store 191 content provided by the original servers, and serves content to the 192 clients located nearby topologically. 194 Live streaming: The scenario where all clients receive streaming 195 content for the same ongoing event. The lags between the play points 196 of the clients and that of the streaming source are small. 198 P2P cache: A P2P cache refers to a network entity that caches P2P 199 traffic in the network, and either transparently or explicitly as a 200 peer distributes content to other peers. 202 P2P streaming protocols: P2P streaming protocols refer to multiple 203 protocols such as streaming control, resource discovery, streaming 204 data transport, etc. which are needed to build a P2P streaming 205 system. 207 Peer/PPSP peer: A peer/PPSP peer refers to a participant in a P2P 208 streaming system. The participant not only receives streaming 209 content, but also stores and uploads streaming content to other 210 participants. 212 PPSP: PPSP refer to the key signaling protocols among various P2P 213 streaming system components including the tracker and peer. PPSP are 214 a part of P2P streaming protocols. 216 Swarm: A swarm refers to a group of clients (i.e. peers) sharing the 217 same content (e.g. video/audio program, digital file, etc) at a given 218 time. 220 Tracker/PPSP tracker: A tracker/PPSP tracker refers to a directory 221 service which maintains lists of peers/PPSP peers storing chunks for 222 a specific channel or streaming file and answers queries from peers/ 223 PPSP peers for peer lists. 225 Video-on-demand (VoD): The scenario where different clients watch 226 different parts of the media recorded and stored during past events. 228 3. Introduction of P2P streaming system 230 There are multiple available P2P streaming solutions. Some are 231 deployed solutions, while others are still under active study. A 232 survey of existing solutions can be found in [Survey]. 234 In P2P streaming system, there are various swarms with each swarm 235 containing a group of clients sharing same streaming content (e.g. 236 channel, streaming file, etc) at a given time. These clients are 237 called peers, as each client not only receives streaming content, but 238 also stores and uploads streaming content to other clients. In a 239 broad sense of global content delivery infrastructure, peers can 240 include multiple types of entities such as end user applications, 241 caches, CDN nodes, and/or other edge devices. Therefore, the basic 242 functions of a P2P streaming system involve: 244 1) Maintaining information about which peers in which swarm in some 245 directory service, a.k.a. tracker. 247 2) In each swarm, exchange information about content availability 248 (e.g. which chunks stored by a peer) among peers, or between tracker 249 and peer. 251 3) In each swarm, exchange the actual content among peers. 253 As shown in Figure 1, common information flows in a P2P streaming 254 system include: 256 1) When a peer wants to receive streaming content: 258 1.1) Peer acquires a list of peers in the swarm from the tracker. A 259 swarm can be indexed by a channel ID, streaming file ID, etc. 261 1.2) Peer exchanges its content availability with the peers on the 262 obtained peer list. 264 1.3) Peer identifies the peers with desired content and requests for 265 the content from the identified peers. 267 2) When a peer wants to share streaming content with others: 269 2.1) Peer sends information to the tracker about the swarms it 270 belongs to, plus streaming status and/or content availability. 272 +----------------------------------------------------+ 273 | +-------------------+ | 274 | | Tracker | | 275 | +-------------------+ | 276 | ^ | ^ | 277 | | | |swarms, | 278 | query | | peer list |streaming status| 279 | | | |and/or content | 280 | | | |availability | 281 | | V | | 282 | +-------------+ +------------+ | 283 | | Peer1 |<------->| Peer 2 | | 284 | +-------------+ content +------------+ | 285 | ^ ^ availability | 286 | * | content | 287 | content * |availability | 288 | * V | 289 | +------------+ | 290 | | Peer 3 | | 291 | +------------+ | 292 +----------------------------------------------------+ 294 Figure 1, Common information flows in P2P streaming system 296 4. Incentives for developing standard PPSP 298 We start by considering the success of the Web. It is the standard 299 HTTP protocol that makes it possible to deploy the global content 300 distribution eco-system that consists of not only end devices such as 301 Web servers and Web clients, but also infrastructure devices such as 302 Web caches and CDN nodes. All of these devices communicate through 303 standard protocols and provide substantial benefits to the consumers, 304 the content publishers, and the network infrastructure. 306 As we discussed in Section 1, given the increasing integration of P2P 307 streaming into the global content delivery infrastructure, 308 proprietary P2P streaming protocols not only result in repetitious 309 development efforts and lock-in effect, but also leads to substantial 310 difficulties when integrating P2P streaming as an integral component 311 of a global content delivery infrastructure. For example, 312 interactions between proprietary P2P streaming protocols and 313 infrastructure devices pose substantial problems. Standard PPSP 314 address these problems and thus provide strong incentives. 316 4.1. P2P streaming and edge cache/CDN support 318 In the context of P2P streaming, infrastructure devices such as edge 319 caches and CDN nodes are also shown as promising means to both 320 improve the performance of P2P streaming (e.g., lower latency) by 321 providing more stable "super peers" and reduce traffic in ISP network 322 [draft-marocco-alto-problem-statement-03][CDN+P2P]. 324 However, there can be substantial obstacles in deploying 325 infrastructure edge devices supporting proprietary P2P streaming 326 protocols [HTPT]. Unlike the Web with the standard HTTP protocol, 327 the current P2P streaming landscape consists of multiple, proprietary 328 P2P streaming protocols mostly differing in signaling transactions. 329 Consequently, in order to support P2P streaming, the infrastructure 330 devices need to understand and keep updated with various proprietary 331 P2P streaming protocols. This introduces complexity and deployment 332 cost of infrastructure devices. 334 With standard PPSP, edge caches and CDN nodes can be designed to 335 inter-operate with only the standard protocols, reducing the 336 complexity and cost to support streaming involving P2P. 338 4.2. Incentive for ISPs 340 Mobility and wireless are becoming increasingly important features to 341 support in future Internet deployments [GENI], [FIND]. For example, 342 China Mobile is developing the Distributed Services Network (DSN) 343 strategy to build its mobile Internet 344 [draft-zhang-ppsp-dsn-introduction-00]. 346 Along with the introduction of mobile and wireless capabilities into 347 the Internet, mobile streaming is becoming a key offered service 348 [MobileTV]. In Korea the number of mobile TV subscriber has reached 349 seventeen millions, accounting for one third of the mobile 350 subscribers. In Italy, there are one million mobile TV users. 351 During the 2008 Beijing Olympic Games, more than one million users 352 utilize China mobile's mobileTV service. 354 Although most current mobile TV deployments are developed in the 355 traditional client/server model, there are clear interests in 356 integrating streaming systems involving P2P into mobile streaming, 357 due to content availability, scalability, and robustness of P2P 358 systems. However, mobile Internet may face more severe bandwidth 359 limitations for supporting P2P streaming. There can be multiple 360 bottlenecks where bandwidth can be limited and the transmission cost 361 can be quite high: a) between mobile terminals and mobile access 362 nodes; b) between mobile access nodes; c) between the mobile network 363 and the fixed network. 365 Standard PPSP can help to address the above challenges. With PPSP, 366 infrastructure devices like mobile gateways and access points can be 367 acted as "Super Peers" and deployed to interact with mobile streaming 368 applications to substantial reduce bandwidth usage on key 369 bottlenecks. 371 It is worth mentioning at this point that the development of PPSP 372 should consider the requirements of mobile Internet. For example, 373 the overhead of PPSP be small in low bandwidth mobile Internet. 374 Also, information exchange in PPSP should support mobility, low 375 battery and heterogeneous capabilities of mobile terminals. 376 Systematic requirements on the development of PPSP will be addressed 377 in the requirements documents. 379 5. Components of P2P streaming system 381 +--------------------------------------------------+ 382 | Application Layer | 383 |--------------------------------------------------| 384 | Play-out Layer | 385 | +----------+ +------------+ +-----------+ | 386 | |start/stop| |pause/resume| | FF/rewind | | 387 | +----------+ +------------+ +-----------+ | 388 |--------------------------------------------------| 389 | Information Layer | 390 | +------------+ +------+ +-----------+ | 391 | |registration| |report| | statistics| | 392 | +------------+ +------+ +-----------+ | 393 |--------------------------------------------------| 394 | Communication Layer | 395 | +---------------------+ +------------------+ | 396 | |tracker communication| |peer communication| | 397 | +---------------------+ +------------------+ | 398 | +-------------+ | 399 | | bootstrap | | 400 | +-------------+ | 401 |--------------------------------------------------| 402 | Transport Layer | 403 +--------------------------------------------------+ 405 Figure 2, Components of P2P streaming system 407 To organize our efforts, we show the components of a complete P2P 408 streaming system in Figure 2. Note that the components in this 409 figure are considered as functional blocks of P2P streaming system. 410 The inter-communication between different layers is for further 411 study. 413 1) Transport Layer is responsible for data transmission between 414 peers. UDP, TCP or other protocols can be used. 416 2) Communication layer includes three components: 418 2.1) Tracker communication is a component that enables each peer to 419 get peer list from the tracker and/or provide content availability to 420 the tracker. 422 2.2) Peer communication is a component that enables each peer to 423 exchange content availability and request other peers for content. 425 2.3) Bootstrap is a component that enables newly joined nodes to 426 obtain tracker information. 428 3) Information layer is responsible for peer and content information 429 collection and management. 431 3.1) Registration is a component that enables nodes to register to 432 the system, and publish the content information. The information may 433 include but is not limited to: content description, content type, 434 creation time, node information such as physical location, IP 435 address. 437 3.2) Report is a component that enables peers to report streaming 438 status to the tracker. The information may include peer inbound/ 439 outbound traffic, amount of neighbor peers, peer health degree and 440 other streaming parameters. 442 3.3) Statistics is a component that enables trackers to manage the 443 aggregated system information for global control in upload bandwidth 444 consumption, overhead consumption and other regards. 446 4) Play-out layer is responsible for controlling the action of media 447 play (e.g. start, pause, resume, stop, fast-forward, and rewind). 449 5) Application layer is the top layer for streaming applications. 451 6. Scope of PPSP 453 6.1. Protocols to be standardized 455 We propose to standardize protocols in PPSP which enable the tracker 456 communication and the peer communication components in the 457 communication layer, as well as the report component in the 458 information layer. These protocols, called PPSP, are key mechanisms 459 involving two important roles - tracker and peer in P2P streaming 460 processes, as addressed in Section 3. These signaling protocols,in 461 essence, aim at standardizing the content information exchange 462 mechanisms among different devices in P2P streaming systems. Note 463 that PPSP are only a part of P2P streaming protocols. The complete 464 set of standard P2P streaming protocols for a whole P2P streaming 465 system could be developed following or parallel to the PPSP work. 467 Because bootstrap, registration and statistics components are out-of- 468 band mechanisms for streaming processes, they are not in current 469 scope of PPSP. Both transport, play-out and application layers in 470 P2P streaming system are also beyond the current scope of PPSP. 472 Therefore, PPSP include the PPSP tracker protocol - a signaling 473 protocol between PPSP trackers and PPSP peers, and the PPSP peer 474 protocol - a signaling protocol among PPSP peers. 476 1) PPSP tracker protocol 478 This protocol will define: 480 1.1) Standard format/encoding of information between PPSP peers and 481 PPSP trackers, such as peer list, content availability, streaming 482 status including online time, link status, node capability and other 483 streaming parameters. 485 1.2) Standard messages between PPSP peers and PPSP trackers defining 486 how PPSP peers report streaming status and request to PPSP trackers, 487 as well as how PPSP trackers reply to the requests. 489 Note that existing protocols should be investigated and evaluated for 490 being reused or extended as the messages between tracker and peer. 491 Possible candidates include the use of the HTTP, where the GET method 492 could be used to obtain peer lists, the POST method used for 493 streaming status reports, etc. 495 2) PPSP peer protocol 497 This protocol will define: 499 2.1) Standard format/encoding of information among PPSP peers, such 500 as chunk description. 502 2.2) Standard messages among PPSP peers defining how PPSP peers 503 advertise chunk availability to each other, as well as the signaling 504 for requesting the chunks among PPSP peers. 506 Again, existing protocols should be investigated and evaluated for 507 being reused or extended as the messages among peers. Possible 508 candidates include the use of the HTTP, where the GET method could be 509 used to obtain chunk availability, etc. Considering the potential 510 large number of peers, some lightweight (possibly binary) protocols 511 could also be good candidates. 513 6.2. Service types to be considered 515 As stated in Section 1, PPSP will serve as enabling technology and 516 tools for building various P2P streaming systems. We are not 517 standardizing certain streaming services. The reason why we list 518 service types here is to show we would consider the properties of 519 these services as the requirements for PPSP design. 521 Common service types supported by current P2P streaming systems 522 include live streaming and video-on-demand (VoD). Note the services 523 listed in this draft are not exhaustive, and more service types are 524 to be involved during the PPSP work. 526 In live streaming, all PPSP peers are interested in the media coming 527 from an ongoing event, which means that all PPSP peers share nearly 528 the same streaming content at a given point of time. In live 529 streaming, some PPSP peers may store the live media for further 530 distribution, which is known as TSTV (time-shift TV) where the stored 531 media are separated into chunks and distributed in a VoD-like manner. 533 In VoD, different PPSP peers watch different parts of the media 534 recorded and stored during a past event. In this case, each PPSP 535 peer keeps asking other PPSP peers which media chunks are stored in 536 which PPSP peers, and then pulls the required media from some 537 selected PPSP peers. 539 7. Use cases of PPSP 541 7.1. Worldwide Provision of P2P Streaming Service with PPSP 543 Consider a popular program, for example the Chinese Spring Festival, 544 where a P2P streaming provider is providing a live media broadcast 545 from China. With existing deployments today, there is very little 546 difficulty in watching the broadcast on the Internet from within 547 China - this is already widespread practice. However if a viewer 548 outside of China wants to watch the gala from outside China, they may 549 have difficulties with smooth playback because of 551 1) Insufficient number of peers outside of China. 553 2) Instability of dynamic peers, which makes meeting condition 1 more 554 difficult. 556 3) No stable end-to-end bandwidth assurance from the source to peers 557 outside China. 559 As stated in section 4, the hybrid CDN and P2P architectures can ease 560 the above difficulties. With the help of PPSP, the P2P streaming 561 provider can quickly leverage other CDN providers' coverage outside 562 its deployment scope. For instance, it may partner with a US CDN 563 provider to provide live streaming to the audience in the USA and may 564 partner with yet another provider to provide services outside of that 565 service provider's scope [Peering CDN] as shown in Fig3. PPSP helps 566 by ensuring the providers have a common protocol to communicate. 567 This reduces the case by case negotiation between the original 568 provider and multiple CDN providers if otherwise proprietary 569 protocols are used makes it easier for both sides to interoperate. 571 The interactions between the P2P streaming provider's tracker server 572 and CDN surrogates as well as interactions between CDN surrogates are 573 the same as a normal peer as shown in Figure 3. 575 This is very useful for a small streaming provider who has no its own 576 CDN surrogates and much money to distribute its stream worldwide. 578 Note that some ISPs have been/are deploying CDN nodes in private 579 networks to improve the user experience. In this sense it's same as 580 a CDN vendor. 582 +-------------------------------------------------------------------+ 583 | | 584 | +------------------------+ | 585 | +------------->| Original Tracker |<--------+ | 586 | | +------------------------+ | | 587 | | ^ ^ | | 588 | Tracker| Tracker | | Tracker |Tracker | 589 |Protocol| Protocol| | Protocol |Protocol| 590 | V V V V | 591 | +---------+ Peer +---------+ +----------+ +---------+ | 592 | | CDN1 |<-------->| CDN2 | | CDN2 | | CDN2 | | 593 | | PoP2 | Protocol | PoP1 | | PoP1 | | PoP2 | | 594 | +---------+ +---------+ +----------+ +---------+ | 595 | ^^ ^ ^ | 596 | Peer || Peer Protocol Peer Protocol | |Peer | 597 |Protocol|+--------------+ +-----+ |Protocol | 598 | V V V V | 599 | +-------+ Peer +------+ +---------+ Peer +---------+| 600 | | USA |<------->| USA | |Caribbean|<------>|Caribbean|| 601 | | User1 |Protocol | User2| | User1 |Protocol| User2 || 602 | +-------+ +------+ +---------+ +---------+| 603 | | 604 | | 605 +-------------------------------------------------------------------+ 607 Figure 3, Worldwide Provision of P2P Streaming Service with PPSP 609 7.2. Hierarchical P2P Streaming Distribution with PPSP 611 The hierarchical P2P streaming distribution have many advantages over 612 non-hierarchical conterparters such as better QoS(start-up latency 613 and service interruption reduction[P2broadcast], higher throughput 614 and lower packets drop ratio[Hybrid], topology-mismatch reduction and 615 better management[AHLSS]. 617 PPSP is useful for clustering the peers with abundant node 618 information and content information exchange to be designed. 620 The simplest hierarchical P2P streaming deployment is just similar to 621 case 7.1 where CDN nodes are in the higher level. Note that PPSP can 622 be applied both in flat and hierarchical P2P streaming distribution. 624 7.3. Unified client software to watch P2P Streaming Programs 626 Currently the users have to install different client software in 627 order to watch different P2P streaming programs since different 628 vendors have generally different programs focus. For example, when a 629 user watches CCTV5 on the Internet, a sports channel with high 630 popularity in Chinese, he may choose PPLive for watching. And when 631 he turns to watch TV series, he tends to use PPStream software.This 632 leads to a lot of P2P streaming software installed in the client. 633 Things become worse in storage and memory constrained devices like 634 mobile handset or TV setbox to install a lot of software. 636 With the help of PPSP, a unified client software can understand 637 different vendors supporting PPSP. Note that this won't affect each 638 vendor's audience group since a user with a unified client watching 639 different vendor's programs is viewed as different users from the 640 vendors' point of view. 642 8. Security Considerations 644 PPSP has a similar assumption in peer privacy as P2PSIP[ID.ietf- 645 p2psip-base], i.e., all participants in the system are issued unique 646 identities and credentials through some mechanism not in the scope of 647 PPSP, such as a centralized server. Hence PPSP will not attempt a 648 solution to these issues for P2P streaming networks in general. 649 However PPSP have some unique security issues: 651 1) The content published by peers may not be checked by centralized 652 certificating server. Therefore P2P streaming network may have the 653 danger of malicious content distribution. 655 2) Content pollution is another common problem faced by P2P 656 streaming. 658 3) Because there is a tracker who is critical to the P2P streaming 659 systems. There is an increased probability that threats may involve 660 launching attacks against the tracker. 662 PPSP may include some mechanisms to prevent malicious nodes from 663 polluting the streaming content or launch attacks to the tracker. 664 The protocol documents will contain a complete description of the 665 security/privacy concerns of PPSP. 667 9. Acknowledgements 669 We would like to acknowledge the following who provided feedback or 670 suggestions for this document: D. Bryan from Cogent Force; E. Marocco 671 from Telecom Italia; V. Gurbani from AT&T; R. Even from Gesher Erove; 672 H. Song, Y, Gu, Lucy Yong from Huawei; H. Zhang from NEC Labs, USA; 673 C. Schmidt and L. Xiao from NSN; C. Williams from ZTE; V. Pasual from 674 Tekelec; X. Zhang from PPlive; H. Deng from China Mobile; and J. Lei 675 from Univ. of Goettingen. 677 10. References 679 10.1. Normative References 681 [ID.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., 682 Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery 683 (RELOAD)Base Protocol", draft-ietf-p2psip-base-02. 685 10.2. Informative References 687 [Cisco] Approaching the Zettabyte Era by Cisco. 689 [PPLive] www.pplive.com 691 [PPStream] www.ppstream.com 693 [UUSee] www.uusee.com 695 [youtube] www.youtube.com 697 [tudou] www.tudou.com 699 [CNN] www.cnn.com 701 [Octoshape] www.octoshape.com 703 [ATT] http://mobile.sooyuu.com/Article/content/200905/ 704 217315094629281_1.shtml 706 [Sigcomm:P2P streaming] Challenges, Design and Analysis of a Large- 707 scale P2P-VoD System,Yan Huang et al, Sigcomm08. 709 [draft-marocco-alto-problem-statement-03] Application-Layer Traffic 710 Optimization (ALTO) Problem Statement, E. Marocco et al, 711 draft-marocco-alto-problem-statement-03 713 [Pando] www.pando.com 715 [CoolStreaming] CoolStreaming/DONet: A Data-Driven Overlay Network 716 for Efficient Live Media Streaming, Xinyan Zhang et al, 718 [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen 719 et al, 721 [draft-zhang-ppsp-protocol-comparison-measurement-00] www.ietf.org/ 722 internet-drafts/ 723 draft-zhang-ppsp-protocol-comparison-measurement-00.txt 725 [GENI] www.geni.net 727 [FIND] www.nets-find.net 729 [draft-zhang-ppsp-dsn-introduction-00] 730 www.ietf.org/internet-draft/draft-zhang-ppsp-dsn-introduction-00.txt 732 [MobileTV] MobileTV,Turning in or switching off, Arthur D. Little 734 [Computer Networks:Traffic] Traffic analysis of peer-to-peer IPTV 735 communities, Thomas Silverston et al, Computer Networks, 53 (2009) 736 470-484 738 [Survey] A survey on peer-to-peer video streaming systems Yong Liu et 739 al, Peer-to-Peer Netw Appl (2008) 1:18-28,Springer. 741 [draft-zhang-alto-traceroute-00] 742 www.ietf.org/internet-draft/draft-zhang-alto-traceroute-00.txt 744 [P2PStreamingSurvey] Zong, N. and X. Jiang, "Survey of P2P 745 Streaming", IETF PPSP BoF, November 2008. 747 [Challenge] Peer-to-Peer Live Video Streaming on the Internet: 748 Issues, Existing Approaches, and Challenges, Bo Li et al, IEEE 749 Communications Magazine, June 2007(94-99). 751 [CDN+P2P] Efficient Large-scale Content Distribution with Combination 752 of CDN and P2P Networks,Hai Jiang et al,International Journal of 753 Hybrid Information Technology, Vol.2, No.2, April, 2009. 755 [Peering CDN] A Case for Peering of Content Delivery Networks, 756 Rajkumar Buyya1 et al, http://dsonline.computer.org/portal/site/ 757 dsonline/menuitem.9ed3d9924aeb0dcd82ccc6716bbe36ec/index.jsp? & 758 pName=dso_level1&path=dsonline/2006/ 759 10&file=o10003.xml&xsl=article.xsl& 761 [P2broadcast] P2broadcast: a hierarchical clustering live video 762 streaming system for P2P networks, De-kai Liu et al,International 763 Journal of Communication Systems,Volume 19,Issue 6. 765 [Hybrid] Hybrid Overlay Networks Management for Real-Time Multimedia 766 Streaming over P2P Networks, Mubashar Mushtaq et al, Lecture Notes in 767 Computer Science, Volume 4787/2007. 769 [AHLSS] AHLSS: A Hierarchical, Adaptive, Extendable P2P Live 770 Streaming System, Runzhi Li et al, International Journal of 771 Distributed Sensor Networks, Volume 5, Issue 1 January 2009. 773 Authors' Addresses 775 Yunfei Zhang 776 China Mobile 778 Email: zhangyunfei@chinamobile.com 780 Ning Zong 781 Huawei Technologies 783 Email: zongning@huawei.com 785 Gonzalo Camarillo 786 Ericsson 788 Email: Gonzalo.Camarillo@ericsson.com 790 James Seng 791 PPLive 793 Email: james.seng@pplive.com 795 Richard Yang 796 Yale University 798 Email: yry@cs.yale.edu