idnits 2.17.1 draft-ietf-ppsp-problem-statement-02.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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 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 734 has weird spacing: '...ltotalo et al...' == 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 (July 4, 2011) is 4680 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Survey' is mentioned on line 107, but not defined == Missing Reference: 'VoD' is mentioned on line 159, but not defined == Missing Reference: 'PPstream' is mentioned on line 117, but not defined == Missing Reference: 'ChinaCache' is mentioned on line 123, but not defined == Missing Reference: 'ComCast' is mentioned on line 124, but not defined == Missing Reference: 'DONA' is mentioned on line 229, but not defined == Missing Reference: 'RayV' is mentioned on line 244, but not defined == Missing Reference: 'Forcetech' is mentioned on line 245, but not defined == Missing Reference: 'HTPT' is mentioned on line 249, but not defined == Missing Reference: 'FIND' is mentioned on line 269, but not defined == Missing Reference: 'MobileTV' is mentioned on line 272, but not defined == Unused Reference: 'Van' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'HPTP' is defined on line 717, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPSP Y.Zhang 2 Internet Draft China Mobile 3 Intended status: Informational N.Zong 4 HuaweiTech 5 G.Camarillo 6 Ericsson 7 J.seng 8 PPlive 9 R.Yang 10 Yale University 11 July 4, 2011 12 Expires: January 2012 14 Problem Statement of P2P Streaming Protocol (PPSP) 15 draft-ietf-ppsp-problem-statement-02.txt 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 This document may contain material from IETF Documents or IETF 23 Contributions published or made publicly available before November 10, 24 2008. The person(s) controlling the copyright in some of this 25 material may not have granted the IETF Trust the right to allow 26 modifications of such material outside the IETF Standards Process. 27 Without obtaining an adequate license from the person(s) controlling 28 the copyright in such materials, this document may not be modified 29 outside the IETF Standards Process, and derivative works of it may 30 not be created outside the IETF Standards Process, except to format 31 it for publication as an RFC or to translate it into languages other 32 than English. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 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 January 4, 2009. 50 Copyright Notice 52 Copyright (c) 2011 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 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents carefully, 59 as they describe your rights and restrictions with respect to this 60 document. Code Components extracted from this document must include 61 Simplified BSD License text as described in Section 4.e of the Trust 62 Legal Provisions and are provided without warranty as described in 63 the Simplified BSD License. 65 Abstract 67 P2P streaming systems show more and more popularity in current 68 Internet with proprietary protocols. This document identifies 69 problems of the proprietary protocols, proposes standard signaling 70 protocols called PPSP and discusses the scope and use cases of PPSP. 72 Table of Contents 74 1. Introduction ................................................ 3 75 2. Conventions used in this document............................ 5 76 3. Problem statement ........................................... 6 77 3.1. Difficulties for ISP in deploying P2P caches ........... 6 78 3.2. Difficult interactionies in building open streaming delivery 79 infrastructure .............................................. 6 80 3.3. Difficulties with in mobile and wireless environment.....7 81 3.4. Difficulties for resource-constraint tTerminals to run 82 different daemons at the same time........................... 8 83 4. PPSP:Standard peer to peer streaming protocols ...............9 84 5. Use cases of PPSP .......................................... 12 85 5.1. Worldwide provision of open P2P live streaming services.12 86 5.2. CDN supporting P2P streaming........................... 13 87 5.3. PPSP supporting cross-screen streaming in heterogeneous 88 environment ................................................ 14 89 5.4. Supporting P2P streaming in cellular mobile network.....14 90 5.5. Cache service supporting P2P streaming .................15 91 6. Security Considerations..................................... 17 92 6.1. Tracker Protocol....................................... 17 93 6.2. Peer Protocol ......................................... 17 94 7. References ................................................. 18 95 8. Acknowledgments ............................................ 20 97 1. Introduction 99 Streaming traffic is among the fastest growing traffic on the 100 Internet. As Cisco Visual Network Traffic index measured, video 101 streaming already generates the largest volume of Internet traffic in 102 the year of 2010, and the percentage is expected to rise to as high 103 as 91% of the total Internet traffic by 2014[Cisco]. 105 There are two basic architectures for delivering streaming traffic on 106 the Internet: the client-server paradigm and the peer to peer (P2P) 107 paradigm [Survey].The basic advantage of the P2P paradigm is its 108 scalability and fault tolerance against failures of centralized 109 infrastructures. As an example, PPLive [PPLive], one of the largest 110 P2P streaming vendors, is able to distribute large-scale, live 111 streaming programs such as the CCTV Spring Festival Gala to more than 112 3 million users with only a handful of servers. It can also deliver 113 VoD streaming to a scale of some hundred of thousands simultaneous 114 users using the same structure and similar protocols[VoD]. The effect 115 of P2P technologies is also well demonstrated in delivering real and 116 VoD streaming effectively in current practice like CNN [CNN] PPstream 117 [PPstream],UUSee [UUSee]and CNTV[CNTV]. The latest release of Adobe 118 Flash, a major platform of streaming distribution in the Internet, 119 has also introduced Cirrus [Cirrus], a peer assisted data exchange 120 mode. 122 What's more, along with the new players like CDN vendors (e.g.,Akamai 123 [Akamai], ChinaCache[ChinaCache]) and ISPs(e.g., ComCast 124 [ComCast])joining in the effort of using P2P streaming delivery in 125 providing their content, the P2P streaming ecosystem is becoming more 126 complex with diverse players varying from the source, infrastructure 127 side, edge delivery side even to the heterogeneous kinds of terminals. 129 Given the increasing integration of P2P streaming into the global 130 content delivery infrastructure, the lacking of an open, standard P2P 131 streaming signaling protocol suite becomes a major missing component 132 in the protocol stack. Almost all these systems use their proprietary 133 signaling protocols. Multiple, similar but proprietary signaling 134 protocols result in repetitious development efforts for new systems, 135 and the lock-in effects lead to substantial difficulties in their 136 integration. For example, in the enhancement of existing caches and 137 CDN systems to support P2P streaming, the open protocols will 138 dynamically reduce the complexity of the interaction with different 139 P2P streaming applications. 141 In this document we propose an open P2P streaming protocol named PPSP, 142 to standardize signaling operations on two important components, peer 143 and tracker in P2P streaming systems for information exchange. The 144 problems of proprietary signaling protocols and benefit of PPSP are 145 explained further in section 3. 147 PPSP will serve as an enabling technology, building on the 148 development experiences of existing P2P streaming systems. Its design 149 will allow it to integrate with IETF protocols on distributed 150 resource location, traffic localization, and streaming control and 151 data transfer mechanisms for building a complete streaming system or 152 updating /integrating existing cache/CDN/routers to support P2P 153 streaming delivery. 155 2. Conventions used in this document 157 Chunk: A chunk is a basic unit of partitioned streaming. Peers may 158 use a chunk as a unit of storage, advertisement and exchange among 159 peers [VoD]. Note that a streaming system may use different units for 160 advertisement and data exchange, using chunks during data exchange, 161 and a larger unit such as a set of chunks during advertisement. 163 Content Distribution Network (CDN): A CDN node refers to a network 164 entity that is deployed in the network (e.g., at the network edge or 165 data centers) to store content provided by the original servers, and 166 serves content to the clients located nearby topologically. 168 Live streaming: It refers to a scenario where all clients receive 169 streaming content for the same ongoing event. It is desired that the 170 lags between the play points of the clients and that of the streaming 171 source be small. 173 P2P cache: A P2P cache refers to a network entity that caches P2P 174 traffic in the network, and either transparently or explicitly as a 175 peer distributes content to other peers. 177 Peer: A peer refers to a participant in a P2P streaming system that 178 not only receives streaming content, but also stores and uploads 179 streaming content to other participants. 181 PPSP: The abbreviation of P2P streaming protocols. PPSP refer to the 182 key signaling protocols among various P2P streaming system components, 183 including the tracker and the peer. 185 Swarm: A swarm refers to a group of clients (i.e., peers) who exchang 186 data to distribute the same content (e.g. video/audio program, 187 digital file, etc) at a given time. 189 Tracker: A tracker refers to a directory server which maintains a 190 list of peers storing chunks for a specific channel or streaming file, 191 and answers queries from peers for peer lists. The tracker is a logic 192 component which can be centralized or distributed. 194 Video-on-demand (VoD): It refers to a scenario where different 195 clients may watch different parts of the same recorded media content 196 during a past event. 198 3. Problem statement 200 The problems brought by proprietary signaling for P2P streaming 201 applications are listed as follows. 203 3.1. Difficulties for ISP in deploying P2P caches 205 Facing with many P2P streaming applications, ISPs are witnessing a 206 big traffic tension on their backbone and inter-networking ports.P2P 207 cache is used to reduce the traffic by dynamically storing the 208 frequently accessed streaming content (maybe in chunk or in file 209 granularity). However, the cache nodes need to execute DPI (deep 210 packet inspection) for identifying different P2P streaming systems. 211 Multiple ever changing proprietary P2P streaming protocols require 212 the P2P cache updating its matching library constantly which 213 increases the operator's cost dramatically. 215 With PPSP, P2P cache can detect P2P streaming applications much 216 easier without needing to update its library. This reduces the ISP 217 workload to a large extent. Note that using standard PPSP won't hurt 218 current P2P streaming vendors : Firstly, the openness of signaling 219 interactions makes it easy to integrate them with ISP's caches for 220 better user experience, say, smaller delay of the play. Secondly, the 221 variation in different P2P streaming systems mainly lies in how the 222 chunks are scheduled to transfer rather than how the chunks 223 availability information is exchanged. The latter is the core of PPSP, 224 which is easiest to be open. 226 3.2. Difficult interactionies in building open streaming delivery 227 infrastructure 229 The future Internet is content-centric [CCN][DONA]because the vast 230 majority of current Internet usage (a "high 90% level of 231 traffic"[Van]) consists of data. Most of the content-centric works 232 are seeking for building an open global content delivery 233 infrastructure,where P2P streaming data delivery is going to account 234 for a large portion. However if current multiple proprietary 235 protocols continue to work, there will exist lots of specific and 236 independent systems to deliver vast of same streaming content. This 237 brings more burdens for identifying and sharing the same contents, 238 increases the storage, forwarding and maintenance cost in the 239 intermediate nodes for repeated content. This will definitely 240 increase the cost of streaming distribution and causes possible 241 congestion in the network. 243 Consider a case where source vendors cooperate with 3rd party CDN. 244 Such integration is already practiced by UUSee[UUSee], RayV[RayV] and 245 Forcetech[Forcetech]. The effect has been verified to improve the 246 total performance of P2P streaming (e.g., with lower latency) by 247 providing more stable "super peers" and reduce traffic for ISP 248 [CDN+P2P] [RFC 5693].However, there are substantial obstacles for CDN 249 nodes supporting proprietary P2P streaming protocols [HTPT]. Unlike 250 the Web where all kinds of the infrastructure devices have been 251 already equipped with standard HTTP protocol,an open CDN supporting 252 various P2P streaming applications need to understand and keep 253 updated on various protocols. Similar to the cache case, this 254 introduces complexity and deployment cost. 256 With PPSP, CDN nodes can be designed to inter-operate with other 257 devices by only standard protocols, reducing the case by case 258 negotiation between the source providers and CDN providers. Note 259 again that we just focus on the standard data availability 260 information interaction between tracker (maybe hosted by the source 261 provider) and CDN nodes, among CDN nodes. The scheduling of data 262 among CDN nodes keeps intact. The interaction between CDN nodes and 263 user peers can be either client/server communication using HTTP or 264 peer to peer communication using PPSP. 266 3.3. Difficulties with in mobile and wireless environment 268 Mobility and wireless are becoming increasingly important features in 269 future Internet deployments [GENI], [FIND]. It is predicted that by 270 the end of 2012, the number of mobile Internet users will surpass 271 that of fixed Internet users in China [Statistics]. Mobile streaming 272 has becoming a key offering [MobileTV]. In Korea the number of mobile 273 TV subscriber has reached seventeen millions, accounting for one 274 third of the mobile subscribers. During the 2008 Beijing Olympic 275 Games, more than one million users enjoyed mobile TV service. There 276 are more and more studies exploring P2P streaming in mobile and 277 wireless networks[Mobile Streaming1] [Mobile Streaming2] 279 However it's difficult to copy current P2P streaming protocols in 280 mobile and wireless networks. Current protocols are designed mainly 281 for fixed Internet. Although smart handsets are more eligible to be 282 peers with much better bandwidth and higher CPU frequency, larger 283 storage and memory than before, peer selection is more challenging 284 which needs more information to exchange during the tracker/peer and 285 peer/peer communications: First, in mobile and wireless networks, the 286 connections are unsteady, lower and costly(esp. in uplink). The 287 trackers and peers need more information, compared to fixed Internet, 288 like packet loss rate, peer battery status and processing capability 289 for peer selection. Note that not all mobile nodes are eligible to be 290 peers. The new-added information should help the tracker/peer to make 291 the decision. Second, current practices often use a "bitmap" message 292 to exchange chunk availability among peers/trackers. The message is 293 often of some kilobytes size and relatively frequent to exchange. In 294 the mobile networks, the bandwidth is scarce and a reasonable 295 optimization is to reduce the message size, which maybe requires a 296 new expression on "bitmap". Third, mobility issue. If a peer is 297 moving from one serving gateway (e.g., GGSN) to another, the IP 298 address will be changed. It may affect the on-going connection and 299 transmission between peers. Therefore such information should be 300 reported in time, which is not addressed in current practices. 302 PPSP should investigate these factors for a practical converged 303 network from the beginning of the design. 305 3.4. Difficulties for resource-constraint tTerminals to run different 306 daemons at the same time 308 Private protocols may require a terminal to install multiple software 309 at the same time. For example a user installs CBox for CCTV programs 310 [CNTV], and PPLive for Japanese and Korean movies [PPLive]. However 311 it may be difficult to install multiple clients in one resource 312 constraint peer like mobile handsets. The limited CPU, storage and 313 memory often limit the total number of installed applications as well 314 as concurrent threads and processes. Note that for many client 315 software, even it's not used by the users right now, the daemon may 316 be invoked to facilitate other peers for free data delivery 317 assistance. Taking storage for example, according to 318 [PPStream][UUSee][PPLive Design], the buffer of each peer's hard disk 319 contributed to the system is at least 1GB. If each mobile peer, like 320 iPhone (version 1) runs 2 such applications at the same time, the 321 storage cannot be shared for different applications and it will 322 consume one fourth of all its storage (8 GB), leaving other data with 323 fewer storage. 325 With PPSP,there is possibility to use one client software to support 326 different applications because the peers can communicate with 327 different trackers/peers with the same protocols and shared 328 buffer( memory and storage). Thus even using different applications 329 at the same time, resource constraint dilemma is largely reduced. The 330 only distinction for different applications lie in different plug-ins 331 (e.g., scheduling algorithms). 333 4. PPSP:Standard peer to peer streaming protocols 335 The objective of this working group is to design PPSP, unified peer 336 to peer streaming protocols to address the problems discussed in the 337 preceding section. 339 There are basically two kinds of P2P streaming systems, pull-based 340 and push-based. In pull-based P2P streaming systems, a centralized 341 tracker or distributed trackers maintains information about which 342 peers are in which swarms and answers the peers' query on such 343 information with a peer-list. After receiving the message, the peer 344 can connect with the candidates in a swarm, exchange its content 345 availability in its memory or storage (depending on it's real-time or 346 VoD streaming) with other peers and then retrieve for wanted 347 streaming data. The swarm is a mesh topology. Most of the current 348 practices are belonging to this genre. The advantages of pull-based 349 mode are its robustness to the peer churn and acceptable latency for 350 a smooth play. On the other hand, in push-based P2P streaming 351 systems, there is a head node maintaining the topology e.g., a tree. 352 The peers in this topology share the same interest on content. The 353 signaling and data distribution are both based on this topology. For 354 one program or video file, the peer queries the head node for its 355 location to join and the head node replies with a peer-list(maybe 356 with recommended order). After receiving this peer-list, the peer can 357 connect with the candidates for being a node in certain place of the 358 topology and receive the data along this topology without the need of 359 exchanging content availability with its siblings. In this sense the 360 head node is acting as the tracker. The push mode has the advantages 361 of lower latency but the topology is fragile to the peer churn. Few 362 practical systems use this mode. A more practical mode is a hybrid 363 pull-push mode where the peers exchange content availability with its 364 siblings for retrieving unfounded data. 366 To sum up, in essence, there are two important entities in P2P 367 streaming, i.e., trackers and peers in P2P streaming systems. PPSP is 368 targeted to standardize the signaling protocols in this tracker-based 369 architectures for supporting both live and VoD streaming. 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 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 What's more, existing protocols should be investigated and evaluated 398 for being reused or extended as the proposed protocols, e.g., HTTP. 399 Considering that there can be a large number of peers, the protocol 400 should consider some lightweight (possibly binary) encoding. 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 vendors can easily expand the broadcasting scale with 432 PPSP. In figure 2 shows the case that vendor A broadcasts the program 433 with the help of vendor B and vendor C for a wider coverage. The 434 interactions between vendor A's tracker and vendor B and vendor C's 435 super-nodes (SN in short) can be normalized using tracker protocol; 436 and peer protocol can be used among SNs/peers spread in different 437 vendors. 439 +-------------------------------------------------------------------+ 440 | | 441 | +------------------+ | 442 | +------------>| A's Tracker |<----------+ | 443 | | +------------------+ | | 444 | Tracker| ^ ^ | | 445 | Protocol| Tracker| |Tracker |Tracker | 446 | | Protocol| |Protocol |Protocol | 447 | | | | | | 448 | | | | | | 449 | v v v v | 450 | +------+ Peer +------+ +------+ +------+ | 451 | | B's |<------->| B's | | C's | | C's | | 452 | | SN1 |Protocol | SN2 | | SN1 | | SN2 | | 453 | +------+ +------+ +------+ +------+ | 454 | ^ ^ ^ ^ | 455 | | | | | | 456 | | | Peer Protocol Peer Protocol| | | 457 | Peer | +-------------+ +--------------+ |Peer | 458 | Procotol| | | |protocol| 459 | | | | | | 460 | | | | | | 461 | | | | | | 462 | v v v v | 463 | +------+ Peer +------+ +---------+ Peer +---------+ | 464 | | A's |<------> | B's | |A's |<------> |C's | | 465 | | User1|Protocol | User2| | User1 |Protocol | User2 | | 466 | +------+ +------+ +---------+ +---------+ | 467 | | 468 +-------------------------------------------------------------------+ 469 Figure 2 Cooperative Vendors Interactions 471 5.2. CDN supporting P2P streaming 473 This scenario is similar to use case 1 except that the intermediate 474 SNs are replaced by 3rd party CDN surrogates with PPSP. The P2P 475 streaming vendors A and B can rent CDN surrogates to provide higher 476 QoS services for VIP users than services provides by only ordinary 477 peers. The interactions among these network entities are shown in 478 Figure 3. The CDN nodes talk with the different trackers and peers 479 with the uniform Tracker and peer protocols. Also it can talk with 480 peers with HTTP if it has complete copy of the requested file. The 481 internal interaction of CDN nodes can be executed by either original 482 internal protocol or new peer protocol. The latter is used when 483 building a new CDN system supporting streaming applications with low 484 cost deploying P2P delivery inside the network. 486 +-------------------------------------------------------------------+ 487 | | 488 | +-------------+ +--------------+ | 489 | +----->| A's Tracker | | B's Tracker |<--+ | 490 | | +-------------+ +--------------+ | | 491 | Tracker| ^ ^ ^ ^ | | 492 | Protocol| Tracker| |Tracker | |Tracker |Tracker | 493 | | Protocol| |Protocol| |Protocol |Protocol | 494 | | | | | | | | 495 | | | | | | | | 496 | v v | | v v | 497 | +------+ Peer +------+ | | +------+Internal+------+ | 498 | | CDN |<------->| CDN | | | | CDN |<------>| CDN | | 499 | | Node1|Protocol | Node2| | | | Node3|Protocol| Node4| | 500 | +------+ +------+ | | +------+ +------+ | 501 | ^ ^ | | ^ ^ | 502 | | | | | | | | 503 | | | Peer Protocol | | HTTP | | | 504 | Peer | +-------------+ | | +------+ | Peer | 505 | Procotol| | | | | Protocol |protocol| 506 | | | +--+ | | | | 507 | | | | | | | | 508 | | | | | | | | 509 | v v v v v v | 510 | +------+ Peer +------+ +---------+ Peer +---------+ | 511 | | A's |<------> | A's | |B's |<------> |B's | | 512 | | User1|Protocol | User2| | User3 |Protocol | User4 | | 513 | +------+ +------+ +---------+ +---------+ | 514 | | 515 +-------------------------------------------------------------------+ 516 Figure 3 CDN Supporting P2P Streaming 518 5.3. PPSP supporting cross-screen streaming in heterogeneous environment 520 In this scenario PC, Setbox/TV and mobile terminals from both fixed 521 network and mobile network share the content they store/cache. Peers 522 from heterogeneous networks 524 With PPSP Peers can identify the types of networks, their load 525 /congestion information, peer abilities and get to know what content 526 other peers have (maybe with the conversion of the content 527 availability expression in different networks) even in different 528 network conditions as shown in Figure 4. These information will play 529 an important role on selecting suitable peers, e.g., a PC or STB node 530 is more likely to be selected to provide stable content for mobile 531 nodes; a mobile peer within a high-load base station is unlikely to 532 be selected, which will lead to higher load on the base station. 534 +-------------------------------------------------------------------+ 535 | | 536 | Tracker Protocol +---------+ Tracker Protocol | 537 | +-------------> | Tracker |<------------------+ | 538 | | +---------+ | | 539 | | ^ | | 540 | | | | | 541 | | | | | 542 | V | V | 543 | +------+ | +------------+ | 544 | | STB | Tracker Protocol |Mobile Phone| | 545 | +------+ | +------------+ | 546 | ^ | ^ | 547 | | | | | 548 | | | | | 549 | | V | | 550 | |Peer Protocol +---------+ Peer Protocol | | 551 | +-------------> | PC |<------------------+ | 552 | +---------+ | 553 | | 554 +-------------------------------------------------------------------+ 555 Figure 4 Heterogeneous P2P Streaming Interactions with PPSP 557 5.4. Supporting P2P streaming in cellular mobile network 559 In a cellular mobile environment like 3G or 4G, with the increase in 560 bandwidth and smart mobile terminal capabilities, P2P (including P2P 561 streaming) is easier to be realized than before. In a provincial 562 network of China Mobile, P2P has accounted for more than 30 563 percentage of the traffic, ranked second except HTTP. 565 Note that the mobile terminals are not compulsorily to be peers. 566 Network peers who are deployed by the ISPs or operators and mobile 567 peers with WiFi connections are more likely to be selected. For 568 example, in 3GPP, there is a P2P CDS work item working on the 569 requirement of mobile operators to prefer use deployed network-side 570 equipments (e.g., serving gateways or GGSNs, one access point from 571 cellular mobile network to the Internet) to act as super-peers when 572 there are no enough eligible peers to realize P2P streaming[P2P CDS]. 573 Because they are deployed by the operators, the stability and storage 574 size are better guaranteed than ordinary peers. 576 Similar with case 5.3, PPSP tracker protocol will help to identify 577 and return the super-peers in the peer-list with preference. If 578 mobile terminals are not eligible to be peers, they can simply 579 receive data from these super-peers without contributing any data to 580 others. 582 5.5. Cache service supporting P2P streaming 584 As discussed in the section3, deploying cache nodes in the network 585 edges can greatly decrease the inter-network traffic and increase 586 user experience in streaming service. 588 With PPSP, the cache nodes can identify the P2P streaming genre even 589 it may include different applications. When a peer requests the 590 streaming data, cache detects the request and requests the frequent 591 visited content (or part of) to the original tracker as a normal peer. 592 The tracker replies with (outward) peers. After the cache connectes 593 with the peers, it can report what it cache to the provider's tracker 594 like a normal peer and serve other requesting peers inside to reduce 595 the cross-ISP traffic as shown in Figure 5. The cache nodes needn't 596 update their library when new applications supporting PPSP are 597 introduced, which enable the cache nodes spend less cost to support 598 more applications. 600 +-----------------------------------------------------------------+ 601 | | 602 | 0:Tracker Protocol +-----------+ | 603 | +------------------>| Tracker | | 604 | | +-----------+ | 605 | | ^ | 606 | | | | 607 | | 2:| Tracker Protocol | 608 | | | | 609 | | +----------|------------------------------| 610 | | | v | 611 | | | +----------+ | 612 | | +---------|---->| Cache |<----------------+ | 613 | | | | +----------+ 1,4:Tracler/Peer| | 614 | | | | Protcol | | 615 | | | | | | 616 | | |3:Peer | | | 617 | | |Protocol | | | 618 | | | | | | 619 | v v | +-----------+| 620 | +-------------+ | ISP Domain | Inside || 621 | | Outward | | | Peer || 622 | | Peer | | +-----------+| 623 | +-------------+ | | 624 +-----------------------------------------------------------------+ 626 Figure 5 Cache Service Supporting Streaming with PPSP 628 6. Security Considerations 630 PPSP will not attempt to provide a solution on security and copyright 631 issues like malicious content distribution, content pollution and DRM 632 for a general P2P streaming system. Instead PPSP security involves 633 the security problems related to PPSP protocols. The protocol 634 documents will contain a complete description on the security/privacy 635 issues relevant to any usage of PPSP. 637 6.1. Tracker Protocol 639 Malicious peers may issue denial of service attack to the trackers by 640 sending large amount of requests with tracker protocol. Distributed 641 trackers deployment may alleviate the problem. 643 On the other hand, malicious peers may report fake information (e.g., 644 cheating trackers and other peers by claiming itself owning some un- 645 existing data). 647 So it may be optional to realize authentication to the peers before 648 accepting the request for the tracker. But this may add up the 649 tracker's workload. 651 In the above discussion tracker is trustful. Things are worse when 652 the malicious peer acts as part of the distributed trackers. The 653 malicious acting tracker may reply the peers with fake peer-list. 654 Peers may find they cannot find desired data with the fake peer-list. 656 6.2. Peer Protocol 658 Similar to the behavior in the tracker-peer interaction, malicious 659 peers may also create fake information on chunk availability and 660 exchange it with other peers. Some techniques to check the data 661 integrity (e.g., using checksum) may be useful for detecting the data. 663 7. References 665 [Cisco] Cisco Visual Networking Index: Forecast and Methodology, 666 2009-2014, 667 http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns7 668 05/ns827/white_paper_c11- 669 481360_ns827_Networking_Solutions_White_Paper.html 671 [PPLive] www.pplive.com 673 [VoD]Challenges, Design and Analysis of a Large-scale P2P-VoD 674 System,Yan Huang et al, Sigcomm08. 676 [CNN] www.cnn.com 678 [PPStream] www.ppstream.com 680 [UUSee] www.uusee.com 682 [CNTV] www.cntv.com 684 [Cirrus] labs.adobe.com/technologies/cirrus/ 686 [Akamai] Understanding hybrid CDN-P2P: why limelight needs its own 687 Red Swoosh, C. Huang et al,Proceedings of the 18th International 688 Workshop on Network and Operating Systems Support for Digital Audio 689 and Video, May 28-30, 2008, Braunschweig, Germany. 691 [ChinaCache]www.chinacache.com 693 [ComCast]http://www.afterdawn.com/news/article.cfm/2008/05/20/comcast 694 _invests_in_p2p_streaming_startup 696 [CCN] Content-Centric Networking,V. Jacobson, 697 https://wiki.tools.isoc.org/@api/deki/files/2634//=1.vj.isoc.mar10.pd 698 f 700 [DONA]A Data-Oriented (and Beyond) Network Architecture, T. Koponen 701 et al, Sigcomm 2007. 703 [Van] A New Way to Look at Networking,Van Jacobson, 704 http://video.google.com/videoplay?docid=-6972678839686672840 706 [RayV]www.rayv.com 708 [Forcetech]http://www.forcetech.net/english/solutions 710 [CDN+P2P]Efficient Large-scale Content Distribution with Combination 711 of CDN and P2P Networks, H. Jiang et al, International Journal of 712 Hybrid Information Technology, Vol.2, No.2, April, 2009. 714 [RFC 5693], Application-Layer Traffic Optimization (ALTO) Problem 715 Statement, E. Marocco et al, http://datatracker.ietf.org/doc/rfc5693/ 717 [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen 718 et al, IPTPS 2007. 720 [GENI] www.geni.net 722 [FIND]www.nets-find.net 724 [Statistics] http://labs.chinamobile.com/news/48283 726 [P2P CDS] 3GPP TR 22.906, Study on IMS based peer-to-peer content 727 distribution services,http://www.3gpp.org/ftp/Specs/html- 728 info/22906.htm 730 [Mobile Streaming1] Streaming To Mobile Users In A Peer-to-Peer 731 Network,Jeonghun Noh et al,MOBIMEDIA '09. 733 [Mobile Streaming2] A real-time peer-to-peer streaming system for 734 mobile networking environment,J. Peltotalo et al., "" in Proceedings 735 of the INFOCOM and Workshop on Mobile Video Delivery (MoVID '09), 736 April 2009. 738 [PPLive Design] Challenges, design and analysis of a large-scale p2p- 739 vod system, Y. Huang, T. Fu, D. Chiu, J. Lui, and C. Huang. ACM 740 SIGCOMM Computer Communication Review, 38(4):375-388, 2008. 742 8. Acknowledgments 744 We would like to acknowledge the following people who provided review, 745 feedback and suggestions to this document: M. Stiemerling;D. Bryan E. 746 Marocco; V. Gurbani; R. Even; H. Zhang; C. Schmidt;L. Xiao; C. 747 Williams; V. Pasual; D. Zhang; J. Lei. 749 Authors' Addresses 751 Yunfei Zhang 753 China Mobile Communication Corporation 755 zhangyunfei@chinamobile.com 757 Ning Zong 759 Huawei Technologies Co., Ltd. 761 zongning@huawei.com 763 Gonzalo Camarillo 765 Ericsson 767 Gonzalo.Camarillo@ericsson.com 769 James Seng 771 PPLive 773 james.seng@pplive.com 775 Richard Yang 777 Yale University 779 yry@cs.yale.edu