idnits 2.17.1 draft-ietf-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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 22 has weird spacing: '...cluding track...' == Line 112 has weird spacing: '...and low load ...' -- The document date (October 29, 2011) is 4560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Survey' is mentioned on line 95, but not defined == Missing Reference: 'Akamai' is mentioned on line 115, but not defined == Missing Reference: 'Forcetech' is mentioned on line 250, but not defined Summary: 2 errors (**), 0 flaws (~~), 6 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 N.Zong 4 HuaweiTech 5 G.Camarillo 6 Ericsson 7 J.seng 8 PPlive 9 R.Yang 10 Yale University 11 Intended status: Informational October 29, 2011 12 Expires: April 2012 14 Problem Statement of Peer-to-Peer Streaming Protocol (PPSP) 15 draft-ietf-ppsp-problem-statement-06.txt 17 Abstract 19 Peer-to-Peer(P2P for short) streaming systems show more and more 20 popularity in current Internet with proprietary protocols. This 21 document identifies problems of the proprietary protocols, proposes a 22 Peer to Peer Streaming Protocol(PPSP) including tracker and peer 23 signaling components, and discusses the scope and uses cases of PPSP. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on April 29, 2009. 47 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents carefully, 56 as they describe your rights and restrictions with respect to this 57 document. Code Components extracted from this document must include 58 Simplified BSD License text as described in Section 4.e of the Trust 59 Legal Provisions and are provided without warranty as described in 60 the Simplified BSD License. 62 Table of Contents 64 1. Introduction .................................................. 4 65 3. Problem statement ............................................. 8 66 3.1. Difficulties for ISPs in deploying P2P caches ............ 8 67 3.2. Difficulties in building open streaming delivery 68 infrastructure ................................................ 8 69 3.3. Difficulties in mobile and wireless environment .......... 9 70 3.4. Difficulties for resource-constrained terminals to run 71 multiple background programs at the same time ................ 10 72 4. PPSP:Standard peer to peer streaming protocols ............... 11 73 5. Use cases of PPSP ............................................ 14 74 5.1. Worldwide provision of open P2P live streaming services . 14 75 5.2. CDN supporting P2P streaming ............................ 15 76 5.3. PPSP supporting cross-screen streaming in heterogeneous 77 environment .................................................. 16 78 5.4. Supporting P2P streaming in cellular mobile network ..... 16 79 5.5. Cache service supporting P2P streaming .................. 17 80 6. Security Considerations ...................................... 19 81 7. IANA Considerations .......................................... 20 82 8. Acknowledgments .............................................. 21 83 9. References ................................................... 22 85 1. Introduction 87 Streaming traffic is among the fastest growing traffic on the 88 Internet. As Cisco Visual Network Traffic index measured, video 89 streaming already generates the largest volume of Internet traffic in 90 the year of 2010, and the percentage is expected to rise to as high 91 as 91% of the total Internet traffic by 2014[Cisco]. 93 There are two basic architectures for delivering streaming traffic on 94 the Internet: the client-server paradigm and the Peer-to-Peer (P2P) 95 paradigm [Survey]. The basic advantage of the P2P paradigm is its 96 scalability and fault tolerance against failures of centralized 97 infrastructures. As an example, PPLive [PPLive], one of the largest 98 P2P streaming vendors, is able to distribute large-scale, live 99 streaming programs such as the CCTV Spring Festival Gala to more than 100 3 million users with only a handful of servers. It can also deliver 101 VoD streaming to a scale of some hundred of thousands simultaneous 102 users using the same structure and similar protocols [VoD]. The 103 effect of P2P technologies is also well demonstrated in delivering 104 real and VoD streaming effectively in current practice like CNN [CNN], 105 PPstream [PPStream],UUSee [UUSee]and CNTV[CNTV]. The latest release 106 of Adobe Flash, a major platform of streaming distribution in the 107 Internet, has also introduced Cirrus [Cirrus], a peer assisted data 108 exchange mode. One point that should also be noted is that P2P 109 approach requires more resources and computational power on the 110 clients (when compared to client-server architecture), as well as a 111 lot of clients to participate in the P2P network for low-lantency, 112 high transmission efficiency and low load on servers . 114 What's more, along with the new players like CDN providers 115 (e.g.,AkamaiNetSession [Akamai], ChinaCache[ChinaCache]) joining in 116 the effort of using P2P streaming delivery in providing their content, 117 the P2P streaming ecosystem is becoming more complex with diverse 118 players varying from the media source, infrastructure side, edge 119 delivery side even to the heterogeneous types of peer or client 120 device platforms.. 122 Given the increasing integration of P2P streaming into the global 123 content delivery infrastructure, the lack of an open, standard P2P 124 streaming signaling protocol suite becomes a major missing component 125 in the protocol stack. Almost all of these systems use their 126 proprietary signaling protocols. Multiple, similar but proprietary 127 signaling protocols result in repetitious development efforts for new 128 systems, and the lock-in effects lead to substantial difficulties in 129 their integration. For example, in the enhancement of existing caches 130 and CDN systems to support P2P streaming, open protocols may reduce 131 the complexity of the interaction with different P2P streaming 132 applications. 134 In this document we propose an open P2P Streaming Protocol, which is 135 defined as PPSP, to standardize signaling operations on two important 136 components, peer and tracker in P2P streaming systems for information 137 exchange. The problems of proprietary signaling protocols and benefit 138 of PPSP are explained further in section 3. 140 PPSP will serve as an enabling technology, building on the 141 development experiences of existing P2P streaming systems. Its design 142 will allow it to integrate with IETF protocols on distributed 143 resource location, traffic localization, and streaming control and 144 data transfer mechanisms for building a complete streaming system or 145 updating /integrating existing cache/CDN to support P2P streaming 146 delivery. 148 2. Terminology and concepts 150 Chunk: A chunk is a basic unit of data block organized in P2P 151 streaming for storage, scheduling, advertisement and exchange among 152 peers [VoD]. A chunk size varies from several KB to several MB in 153 different systems. In case of MB size chunk scenario, a sub-chunk 154 structure named piece is often defined to fit in a single transmitted 155 packet. A streaming system may use different granularities for 156 different usage, e.g., using chunks during data exchange, and using a 157 larger unit such as a set of chunks during advertisement. 159 Content Distribution Network (CDN): A CDN node refers to a network 160 entity that is deployed in the network (e.g., at the network edge or 161 data centers) to store content provided by the original servers, and 162 serves content to the clients located nearby topologically. 164 Client: A client refers to the service requester in client/server 165 computing paradigm. In this draft a client refers to a participant in 166 a P2P streaming system that only receives streaming content. In some 167 cases the node is not eligible to be a peer without enough computing 168 and storage capability is acting as a client. It can be viewed as a 169 specific kind of peer. 171 Live streaming: It refers to a scenario where all clients receive 172 streaming content for the same ongoing event. It is desired that the 173 lags between the play points of the clients and that of the streaming 174 source be small. 176 P2P cache: A P2P cache refers to a network entity that caches P2P 177 traffic in the network, and either transparently or explicitly as a 178 peer distributes content to other peers. 180 Peer: A peer refers to a participant in a P2P streaming system that 181 not only receives streaming content, but also stores and uploads 182 streaming content to other participants. 184 PPSP: The abbreviation of Peer-to-Peer Streaming Protocols. PPSP 185 refer to the key signaling protocols among various P2P streaming 186 system components, including the tracker and the peer. 188 Swarm: A swarm refers to a group of peers who exchange data to 189 distribute chunks of the same content(e.g. video/audio program, 190 digital file, etc) at a given time. 192 Tracker: A tracker refers to a directory server which maintains a 193 list of peers which participate in a specific video channel or in the 194 distribution of a streaming file, and answers queries from peers for 195 peer lists. The tracker is a logical component which can be 196 centralized or distributed. 198 Video-on-demand (VoD): It refers to a scenario where different 199 clients may watch different parts of the same recorded media with 200 downloaded content. 202 3. Problem statement 204 The problems imposed by proprietary signaling for P2P streaming 205 applications are listed as follows. 207 3.1. Difficulties for ISPs in deploying P2P caches 209 Facing with many P2P streaming applications, ISPs are witnessing a 210 big traffic tension on their backbone and inter-networking points.P2P 211 caches are used to reduce the traffic by dynamically storing the 212 frequently accessed streaming content (maybe in chunk or in file 213 granularity). However, the cache nodes need to execute DPI (deep 214 packet inspection) for identifying different P2P streaming systems. 215 Multiple ever changing proprietary P2P streaming protocols require 216 the P2P cache updating its matching library constantly which 217 increases the operator's cost dramatically. 219 With PPSP, P2P caches should be able to detect P2P streaming 220 applications much easier without needing to update its library, as 221 there should be only a single protocol to be detected and not a 222 potentially unknown set of proprietary P2P protocols. This would 223 reduce the ISP workload to a large extent. Note that using standard 224 PPSP would not hurt current P2P streaming providers: Firstly, the 225 openness of signaling interaction would make it easy to integrate 226 them with ISP's caches for better user experience, say, smaller delay 227 of the play. Secondly, different applications could use PPSP for 228 signaling, but implement something system specific on top of that. 229 That is to say, different P2P streaming systems compete on "on top" 230 things, like scheduling algorithms, which is independent of how the 231 peers exchange chunk availability. In other words, different systems 232 should be able to have quite different scheduling algorithms with 233 same tracker/peer protocol, which is easier to be open. 235 3.2. Difficulties in building open streaming delivery infrastructure 237 More and more efforts are seeking for building an open global 238 streaming delivery infrastructure, where systems using P2P account 239 for a large portion. However if current multiple proprietary 240 protocols continue to work, there will exist lots of specific and 241 independent systems to deliver vastlythe same streaming content. This 242 brings more burdens for identifying and sharing the same contents, 243 and increases the storage, forwarding and maintenance cost in the 244 intermediate nodes for repeated content. This will definitely 245 increase the cost of streaming distribution and causes possible 246 congestion in the network. 248 Consider a case where source vendors cooperate with 3rd party CDN 249 providers. Such integration is already practiced by UUSee[UUSee], 250 RayV[RayV] and Forcetech[Forcetech]. The effect has been verified to 251 improve the total performance of P2P streaming (e.g., with lower 252 latency) by providing more stable "super peers" and reduce traffic 253 for ISP [CDN+P2P] [RFC 5693].However, there are substantial obstacles 254 for CDN nodes supporting proprietary P2P streaming protocols [HPTP]. 255 Unlike the Web where all kinds of the infrastructure devices have 256 been already equipped with standard HTTP protocol, an open CDN 257 supporting various P2P streaming applications need to understand and 258 keep updated on various protocols. Similar to the caching case in 259 Section 3.1, this introduces complexity and deployment cost. 261 With PPSP, CDN nodes can be designed to inter-operate with other 262 devices by only standard protocols, reducing the case by case 263 negotiation between the P2P streaming providers and CDN providers.On 264 the other side, the interface between CDN nodes and user peers could 265 be via something like traditional HTTP requests, or could be via PPSP 266 for streaming setup. 268 3.3. Difficulties in mobile and wireless environment 270 Mobility and wireless are becoming increasingly important features in 271 today's Internet. It is predicted that by the end of 2012, the number 272 of mobile Internet users will surpass that of fixed Internet users in 273 China [Statistics]. Mobile streaming has becoming a key offering. In 274 Korea the number of mobile TV subscriber has reached seventeen 275 million, accounting for one third of the mobile subscribers. During 276 the 2008 Beijing Olympic Games, more than one million users enjoyed 277 mobile TV service. There are multiple prior studies exploring P2P 278 streaming in mobile and wireless networks [Mobile Streaming1] [Mobile 279 Streaming2]. 281 However it's difficult to copy current P2P streaming protocols in 282 mobile and wireless networks. Current protocols are designed mainly 283 for fixed Internet. Although smart handsets are more eligible to be 284 peers with much better bandwidth and higher CPU frequency, larger 285 storage and memory than before, peer selection is more challenging 286 which needs more information to exchange during the tracker/peer and 287 peer/peer communications: First, in mobile and wireless networks, the 288 connections are unsteady, lower rate, and costly in terms of energy 289 consumption and transmission(esp. in uplink). The trackers and peers 290 may need more information, compared to fixed Internet, like packet 291 loss rate, peer battery status and processing capability for peer 292 selection. Note that not all mobile nodes are eligible to be peers. 293 Second, current practices often use a "bitmap" message to exchange 294 chunk availability among peers/trackers. The message is often of some 295 kilobytes size and exchanged relatively frequently. In the mobile 296 networks, the bandwidth is scarce and a reasonable optimization is to 297 reduce the message size, whichmay require alternative methods for 298 expressing and distributing bitmap information. Third, mobility issue. 299 When a peer is moving and the IP address changes, the on-going 300 connection and transmission between peers may be affected. Therefore 301 such information should be reported in time, which is not addressed 302 in current practices. 304 PPSP should investigate these factors for a practical converged 305 network from the beginning of the design. 307 3.4. Difficulties for resource-constrained terminals to run multiple 308 background programs at the same time 310 Private protocols may require a terminal to install different 311 software for different applications. Note that for many client 312 software, even it's not used by the users right now, the background 313 program may be invoked to facilitate other peers for free data 314 delivery assistance. In other words, there will be multiple 315 background programs running at the same time. However it may be 316 difficult to invoke multiple programs in a resource constraint peer 317 like mobile handsets or settop boxes (STBs). The limited CPU, storage 318 and memory often limit the total number of concurrent threads and 319 processes. Taking storage for example, according to 320 [PPStream][UUSee][PPLive Design], the buffer of each peer's hard disk 321 contributed to the system is at least 1GB. If each mobile peer, like 322 iPhone (version 1) runs two such background applications at the same 323 time, the storage cannot be shared for different applications and it 324 will consume one fourth of all its storage (8 GB), leaving other data 325 with fewer storage. 327 PPSP can help to reduce the resource consumption like RAM usage on 328 resource constraint devices, such as STBs or mobile phones, by 329 reusing a PPSP base library and potentially other optimizations. 331 4. PPSP:Standard peer to peer streaming protocols 333 The objective of the PPSP working group is to design a unified peer- 334 to-peer streaming protocol (PPSP) to address the problems discussed 335 in the preceding sections. 337 There are basically two kinds of P2P streaming systems, pull-based 338 and push-based. 340 In pull-based P2P streaming systems, a centralized tracker or 341 distributed trackers maintains information about which peers are in 342 which swarms and answers the peers' query on such information with a 343 peer-list. After receiving the message, the peer can connect with the 344 candidates in a swarm, exchange its content availability in its 345 memory or storage (depending on it's real-time or VoD streaming) with 346 other peers and then retrieve the wanted streaming data. The swarm is 347 a mesh topology. Most of the current practices belong to this genre. 348 The advantages of pull-based mode are its robustness to the peer 349 churn and acceptable latency for a smooth play. 351 In push-based P2P streaming systems, there is a head node maintaining 352 the topology, e.g., a tree. The peers in this topology share the same 353 interest on content. The signaling and data distribution are both 354 based on this topology. For one program or video file, the peer 355 queries the head node by offline or pre-set head node address 356 information for its location to join and the head node replies with a 357 peer-list(potentially in a recommended order). After receiving this 358 peer-list, the peer can connect with the candidates for being a node 359 in certain place of the topology and receive the data along this 360 topology without the need of exchanging content availability with its 361 siblings, as done in pull-based mode. In this sense the head node is 362 acting as the tracker in the pull-based mode. The push mode has the 363 advantages of lower latency but the topology is fragile to the peer 364 churn. Few commercially deployed systems use this mode. 366 A more practical mode is a hybrid pull-push mode where the peers join 367 the system in the same way as in push-based mode while also exchange 368 content availability with its siblings for retrieving requsted data, 369 just like pull-based mode. 371 In live streaming, all peers are interested in the media coming from 372 an ongoing event, which means that all peers share nearly the same 373 streaming content at a given point of time. In live streaming, some 374 peers may store the live media for further distribution, which is 375 known as TSTV (time-shift TV), where the stored media are separated 376 into chunks and distributed in a VoD-like manner. 378 In VoD, different peers watch different parts of the recorded media 379 content during a past event. In this case, each peer keeps asking 380 other peers which media chunks are stored in which peers, and then 381 gets the required media from certain/selected peers. 383 To sum up, in essence, there are two important entities in P2P 384 streaming, i.e., trackers and peers in P2P streaming systems. PPSP 385 includes standard signaling protocols for tracker-based architectures 386 that support either live or offline streaming. 388 The PPSP design includes a protocol for signaling between trackers 389 and peers (the PPSP "tracker protocol") and a signaling protocol for 390 communication among the peers (the PPSP "peer protocol") as shown in 391 Figure 1.The two protocols enable peers to receive streaming data 392 within the time constraints required by specific content items. The 393 tracker protocol handles the initial and periodic exchange of meta 394 information between trackers and peers, such as peer-list and content 395 information. The peer protocol controls the advertising and exchange 396 of media data between the peers. 398 Note that in the pull mode and hybrid pull-push mode, both tracker 399 protocol and peer protocol can be used; while in the push mode, only 400 tracker protocol is used. 402 +------------------------------------------------+ 403 | | 404 | +--------------------------------+ | 405 | | Tracker(Head Node) | | 406 | +--------------------------------+ | 407 | | ^ ^ | 408 |Tracker | | Tracker |Tracker | 409 |Protocol| | Procotol |Protocol | 410 | | | | | 411 | V | | | 412 | +---------+ Peer +---------+ | 413 | | Peer |<----------->| Peer | | 414 | +---------+ Protocol +---------+ | 415 | | ^ | 416 | | |Peer | 417 | | |Protocol | 418 | V | | 419 | +---------------+ | 420 | | Peer | | 421 | +---------------+ | 422 | | 423 | | 424 +------------------------------------------------+ 425 Figure 1 PPSP System Architecture 427 5. Use cases of PPSP 429 5.1. Worldwide provision of open P2P live streaming services 431 The cooperative content providers can easily expand the broadcasting 432 scale with PPSP. In figure 2 shows the case that provider A 433 broadcasts the program with the help of provider B and C for a wider 434 coverage. The content providers often deploy in-network peers called 435 super-nodes (SN for short) with better stability and higher storage 436 and bandwidth compared with user peers for better QoS. The 437 interaction between A's tracker and vendor B and vendor C's SNs can 438 be normalized using tracker protocol; and peer protocol can be used 439 among SNs/peers spread in different vendors. 441 +-------------------------------------------------------------------+ 442 | | 443 | +------------------+ | 444 | +------------>| A's Tracker |<----------+ | 445 | | +------------------+ | | 446 | Tracker| ^ ^ | | 447 | Protocol| Tracker| |Tracker |Tracker | 448 | | Protocol| |Protocol |Protocol | 449 | | | | | | 450 | | | | | | 451 | v v v v | 452 | +------+ Peer +------+ +------+ +------+ | 453 | | B's |<------->| B's | | C's | | C's | | 454 | | SN1 |Protocol | SN2 | | SN1 | | SN2 | | 455 | +------+ +------+ +------+ +------+ | 456 | ^ ^ ^ ^ | 457 | | | | | | 458 | | | Peer Protocol Peer Protocol| | | 459 | Peer | +-------------+ +--------------+ |Peer | 460 | Procotol| | | |protocol| 461 | | | | | | 462 | | | | | | 463 | | | | | | 464 | v v v v | 465 | +------+ Peer +------+ +---------+ Peer +---------+ | 466 | | A's |<------> | B's | |A's |<------> |C's | | 467 | | User1|Protocol | User2| | User1 |Protocol | User2 | | 468 | +------+ +------+ +---------+ +---------+ | 469 | | 470 +-------------------------------------------------------------------+ 471 Figure 2 Cooperative Vendors Interaction 473 5.2. CDN supporting P2P streaming 475 This scenario is similar to use case 1 except that the intermediate 476 SNs are replaced by 3rd party CDN surrogates with PPSP. The P2P 477 streaming vendors A and B can rent CDN surrogates to provide higher 478 QoS services for VIP users than services provides by only ordinary 479 peers. The interaction among these network entities are shown in 480 Figure 3. The CDN nodes talk with the different trackers and peers 481 with the uniform Tracker and peer protocols. It can also communicate 482 with end users using HTTP for legacy equipments. The internal 483 interaction of CDN nodes can be executed by either original internal 484 protocol or new peer protocol. The latter is used when building a new 485 CDN system supporting streaming applications with low cost deploying 486 P2P delivery inside the network. 488 +-------------------------------------------------------------------+ 489 | | 490 | +-------------+ +--------------+ | 491 | +----->| A's Tracker | | B's Tracker |<---+ | 492 | | +-------------+ +--------------+ | | 493 | Tracker| ^ ^ ^ ^ | | 494 | Protocol| Tracker| |Tracker | |Tracker |Tracker | 495 | | Protocol| |Protocol| |Protocol |Protocol| 496 | | | | | | | | 497 | | | | | | | | 498 | v v | | v v | 499 | +------+ Peer +------+| | +------+Internal+------+ | 500 | | CDN |<------>| CDN || | | CDN |<-----> | CDN | | 501 | | Node1|Protocol| Node2|| | | Node3|Protocol| Node4| | 502 | +------+ +------+| | +------+ +------+ | 503 | ^ ^ | | ^ ^ | 504 | | | | | | | | 505 | | | Peer Protocol | | HTTP | | | 506 | Peer | +-------------+ | | +------+ | Peer | 507 | Procotol| | | | | Protocol |protocol| 508 | | | +-+ | | | | 509 | | | | | | | | 510 | | | | | | | | 511 | v v v v v v | 512 | +------+ Peer +------+ +---------+ Peer +---------+ | 513 | | A's |<------> | A's | |B's |<------> |B's | | 514 | | User1|Protocol | User2| | User3 |Protocol | User4 | | 515 | +------+ +------+ +---------+ +---------+ | 516 | | 517 +-------------------------------------------------------------------+ 518 Figure 3 CDN Supporting P2P Streaming 520 5.3. PPSP supporting cross-screen streaming in heterogeneous environment 522 In this scenario PC, Setbox/TV and mobile terminals from both fixed 523 network and mobile network share the content they store/cache. Peers 524 from heterogeneous networks 526 With PPSP,peers can identify the types of access networks, average 527 load, peer abilities and get to know what content other peers have 528 (potentially with the conversion of the content availability 529 expression in different networks) even in different network 530 conditions as shown in Figure 4. These information will play an 531 important role on selecting suitable peers, e.g., a PC or STB node is 532 more likely to be selected to provide stable content for mobile nodes; 533 a mobile peer within a high-load base station is unlikely to be 534 selected, which may lead to higher load on the base station. 536 +-------------------------------------------------------------------+ 537 | | 538 | Tracker Protocol +---------+ Tracker Protocol | 539 | +-------------> | Tracker |<------------------+ | 540 | | +---------+ | | 541 | | ^ | | 542 | | | | | 543 | | | | | 544 | V | V | 545 | +------+ | +------------+ | 546 | | STB | Tracker Protocol |Mobile Phone| | 547 | +------+ | +------------+ | 548 | ^ | ^ | 549 | | | | | 550 | | | | | 551 | | V | | 552 | |Peer Protocol +---------+ Peer Protocol | | 553 | +-------------> | PC |<------------------+ | 554 | +---------+ | 555 | | 556 +-------------------------------------------------------------------+ 557 Figure 4 Heterogeneous P2P Streaming Interaction with PPSP 559 5.4. Supporting P2P streaming in cellular mobile network 561 In a cellular mobile environment like 3G or 4G, with the increase in 562 bandwidth and smart mobile terminal capabilities, P2P (including 563 P2Pstreaming ) is easier to be realized than before. In a provincial 564 network of China Mobile, P2P has accounted for more than 30 565 percentage of the traffic, ranked second. 567 Note that the mobile terminals are not compulsorily to be peers. Here 568 they act as clients. Network peers who are deployed by the ISPs or 569 operators and mobile peers with WiFi connections are more likely to 570 be selected. For example, in 3GPP, there is a P2P Content 571 Distribution Service (P2P CDS) work item working on the requirement 572 of mobile operators to prefer use deployed network-side equipments 573 (e.g., serving gateways or GGSNs, one access point from cellular 574 mobile network to the Internet) to act as super-peers when there are 575 no enough eligible peers to realize P2P streaming[P2P CDS]. Because 576 they are deployed by the operators, the stability and storage size 577 are better guaranteed than ordinary peers. 579 Similar with case 5.3, PPSP tracker protocol will help to identify 580 and return the super-peers in the peer-list with preference. If 581 mobile terminals are not eligible to be peers, they can simply 582 receive data from these super-peers without contributing any data to 583 others. 585 5.5. Cache service supporting P2P streaming 587 To greatly decrease the inter-network traffic and increase user 588 experience in P2P streaming services, an ISP may deploy cache service 589 in its network. 591 In Figure 5, when peers request the P2P streaming data, the cache 592 nodes intercept the requests and ask for the frequently visited 593 content (or part of) on behalf of the user peers. To do this, it 594 requests peer-list to the tracker and the tracker replies with 595 (outward) peers. After the cache nodes exchange data with these peers, 596 it can report what it cache to the tracker like a normal peer and 597 serve other requesting peers inside. 599 The cache nodes needn't update their library when new applications 600 supporting PPSP are introduced, which enable the cache nodes spend 601 less cost to support more applications. 603 +----------------------------------------------------------------+ 604 | | 605 | 0:Tracker Protocol +---------+ | 606 | +----------------> | Tracker | | 607 | | +---------+ | 608 | | ^ | 609 | | | | 610 | | 2: | Tracker Protocol | 611 | | | | 612 | | | | 613 | | +---------|-------------------------------------| 614 | | | V | 615 | | | +---------+ | 616 | | +----------|---> | Cache |<-------------------+ | 617 | | | | +---------+ 1,4: Tracker/Peer| | 618 | | |3: Peer | Protocol | | 619 | | | Protocol | | | 620 | | | | | | 621 | | | | | | 622 | V V | V | 623 | +-----------+ | ISP Domain +------------+ | 624 | | Outward | | | Inside | | 625 | | Peer | | | Peer | | 626 | +-----------+ | +------------+ | 627 +----------------------------------------------------------------+ 629 Figure 5 Cache Service Supporting Streaming with PPSP 631 6. Security Considerations 633 This document discusses the problem statement around Peer-to-Peer 634 streaming protocols without specifying the protocols. The protocol 635 specification is deferred to other documents under development in the 636 PPSP working group. However we believe it is important for the reader 637 to understand areas of security caused by the P2P nature of the 638 proposed solution. The main issue is the usage of untrusted entities 639 (peers) for service provisioning. 641 Malicious peers may, for example: 643 - Issue denial of service (DOS) attacks to the trackers by sending 644 large amount of requests with the tracker protocol; 646 - Issue fake information on behalf of other peers; 648 - Issue fake information about available content; 650 - Issue fake information about chunk availability; 652 Malicious peers/trackers may, for example: 654 - Issue reply instead of the regular tracker (man in the middle 655 attack). 657 The PPSP protocol specifications, e.g., the tracker protocol and the 658 peer protocol, will document the expected threats and how they will 659 be mitigated for each protocol, but also considerations on threats 660 and mitigations when combining both protocols in an application. This 661 will include privacy of the users, protection of the content 662 distribution, but not protection of the content by Digital Rights 663 Management (DRM). 665 7. IANA Considerations 667 This document has no actions for IANA. 669 8. Acknowledgments 671 We would like to acknowledge the following people who provided review, 672 feedback and suggestions to this document: M. Stiemerling; C. Schmidt; 673 D. Bryan; E. Marocco; V. Gurbani; R. Even; H. Zhang; L. Xiao; C. 674 Williams; V. Pasual; D. Zhang; J. Lei. 676 This document was prepared using 2-Word-v2.0.template.dot. 678 9. References 680 [RFC 5693], Application-Layer Traffic Optimization (ALTO) Problem 681 Statement, E. Marocco et al, 682 http://datatracker.ietf.org/doc/rfc5693/ 684 [Cisco] Cisco Visual Networking Index: Forecast and Methodology, 685 2009-2014, 686 http://www.cisco.com/en/US/solutions/collateral/ns341/ns525 687 /ns537/ns705/ns827/white_paper_c11- 688 481360_ns827_Networking_Solutions_White_Paper.html 690 [PPLive] www.pplive.com 692 [VoD] Yan Huang et al,Challenges, "Design and Analysis of a Large- 693 scale P2P-VoD System", Sigcomm08. 695 [CNN] www.cnn.com 697 [PPStream] www.ppstream.com 699 [UUSee] www.uusee.com 701 [CNTV] www.cntv.com 703 [Cirrus] Cirrus, Use RTMFP for developing real-time collaboration 704 applications, labs.adobe.com/technologies/cirrus/ 706 [Akamai]Peer-to-Peer Systems, Rodrigo Rodrigues et al, Communications 707 of the ACM,Vol. 53 No. 10, Pages 72-82. 708 http://cacm.acm.org/magazines/2010/10/99498-peer-to-peer- 709 systems/fulltext 711 [ChinaCache] RawFlow partners with ChinaCache: Creating Asia's 712 largest P2P powered live media delivery network, 714 http://www.redorbit.com/news/technology/813722/rawflow_partners_with_ 715 chinacache_creating_asias_largest_P2P_powered_live/ 717 [Survey]Yong Liu et al,"A survey on Peer-to-Peer video streaming 718 systems", Peer to Peer Networking and Applications,Volume 1, 719 Number 1,18-28,Springer,2008. 721 [RayV] www.rayv.com 723 [Forcetech]http://www.forcetech.net/english/solutions 725 [CDN+P2P] H. Jiang et al,"Efficient Large-scale Content Distribution 726 with Combination of CDN and P2P Networks", International 727 Journal of Hybrid Information Technology, Vol.2, No.2, 728 April, 2009. 730 [HPTP] HPTP: Relieving the Tension between ISPs and P2P, GuobinShen 731 et al, IPTPS 2007. 733 [Statistics] China's mobile Internet users to surpass Internet users 734 in 2012, http://www.mspnews.com/news/2011/02/15/5312461.htm 736 [P2P CDS] 3GPP TR 22.906, Study on IMS based Peer-to-Peer content 737 distribution services,http://www.3gpp.org/ftp/Specs/html- 738 info/22906.htm 740 [Mobile Streaming1] Streaming to Mobile Users in a Peer-to-Peer 741 Network,Jeonghun Noh et al,MOBIMEDIA '09. 743 [Mobile Streaming2] J. Peltotaloet al.,"A real-time Peer-to-Peer 744 streaming system for mobile networking environment", in 745 Proceedings of the INFOCOM and Workshop on Mobile Video 746 Delivery (MoVID '09), April 2009. 748 [PPLive Design] Y. Huang, T. Fu, D. Chiu, J. Lui, and C. 749 Huang ,"Challenges, design and analysis of a large-scale 750 P2P-vod system", ACM SIGCOMM Computer Communication Review, 751 38(4):375-388, 2008. 753 Authors' Addresses 755 Yunfei Zhang 756 China Mobile Communication Corporation 757 zhangyunfei@chinamobile.com 759 NingZong 760 Huawei Technologies Co., Ltd. 761 zongning@huawei.com 763 Gonzalo Camarillo 764 Ericsson 765 Gonzalo.Camarillo@ericsson.com 767 James Seng 768 PPLive 769 james.seng@pplive.com 771 Richard Yang 772 Yale University 773 yry@cs.yale.edu 775 Authors' Addresses 777 778 779
781 Phone: 782 Email: 784 785 786
788 Phone: 789 Email: