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