idnits 2.17.1 draft-ietf-ppsp-problem-statement-03.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 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 == Line 749 has weird spacing: '...ltotalo et al...' -- The document date (August 12, 2011) is 4613 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: 'VoD' is mentioned on line 151, but not defined == Missing Reference: 'PPstream' is mentioned on line 105, but not defined == Missing Reference: 'Akamai' is mentioned on line 115, but not defined == Missing Reference: 'RayV' is mentioned on line 245, but not defined == Missing Reference: 'Forcetech' is mentioned on line 246, but not defined == Missing Reference: 'MobileTV' is mentioned on line 273, but not defined == Unused Reference: 'Van' is defined on line 718, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 10 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 Expires: Feb 12,2012 August 12, 2011 13 Problem Statement of P2P Streaming Protocol (PPSP) 14 draft-ietf-ppsp-problem-statement-03.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on February 12, 2009. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents carefully, 47 as they describe your rights and restrictions with respect to this 48 document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Abstract 55 P2P streaming systems show more and more popularity in current 56 Internet with proprietary protocols. This document identifies 57 problems of the proprietary protocols, proposes standard signaling 58 protocols called PPSP and discusses the scope and use cases of PPSP. 60 Table of Contents 62 1. Introduction ................................................ 4 63 2. Terminology and concepts .....................................6 64 3. Problem statement ........................................... 8 65 3.1. Difficulties for ISP in deploying P2P caches ............8 66 3.2. Difficulties in building open streaming delivery 67 infrastructure .............................................. 8 68 3.3. Difficulties in mobile and wireless environment ........ 9 69 3.4. Difficulties for resource-constraint terminals to run 70 multiple background programs at the same time ............... 10 71 4. PPSP:Standard peer to peer streaming protocols .............. 11 72 5. Use cases of PPSP ........................................... 14 73 5.1. Worldwide provision of open P2P live streaming services .14 74 5.2. CDN supporting P2P streaming ........................... 15 75 5.3. PPSP supporting cross-screen streaming in heterogeneous 76 environment ................................................. 16 77 5.4. Supporting P2P streaming in cellular mobile network .....16 78 5.5. Cache service supporting P2P streaming ................. 17 79 6. Security Considerations ..................................... 19 80 6.1. Tracker Protocol ....................................... 19 81 6.2. Peer Protocol .......................................... 19 82 7. Acknowledgments ............................................. 20 83 8. References .................................................. 21 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 effect 103 of P2P technologies is also well demonstrated in delivering real and 104 VoD streaming effectively in current practice like CNN [CNN] PPstream 105 [PPstream],UUSee [UUSee]and CNTV[CNTV]. The latest release of Adobe 106 Flash, a major platform of streaming distribution in the Internet, 107 has also introduced Cirrus [Cirrus], a peer assisted data exchange 108 mode. One point that should also be noted is that P2P approach 109 requires more resources and computational power on the clients (when 110 compared to Client-Server architecture), as well as a lot of clients 111 to participate in the P2P network for the network to be efficient. 112 This is less challenging for highly increasing capability on hardware. 114 What's more, along with the new players like CDN providers 115 (e.g.,Akamai NetSession [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 source, infrastructure side, edge delivery 119 side even to the heterogeneous kinds of terminals. 121 Given the increasing integration of P2P streaming into the global 122 content delivery infrastructure, the lacking of an open, standard P2P 123 streaming signaling protocol suite becomes a major missing component 124 in the protocol stack. Almost all these systems use their proprietary 125 signaling protocols. Multiple, similar but proprietary signaling 126 protocols result in repetitious development efforts for new systems, 127 and the lock-in effects lead to substantial difficulties in their 128 integration. For example, in the enhancement of existing caches and 129 CDN systems to support P2P streaming, the open protocols will 130 dynamically reduce the complexity of the interaction with different 131 P2P streaming applications. 133 In this document we propose an open P2P streaming protocol named PPSP, 134 to standardize signaling operations on two important components, peer 135 and tracker in P2P streaming systems for information exchange. The 136 problems of proprietary signaling protocols and benefit of PPSP are 137 explained further in section 3. 139 PPSP will serve as an enabling technology, building on the 140 development experiences of existing P2P streaming systems. Its design 141 will allow it to integrate with IETF protocols on distributed 142 resource location, traffic localization, and streaming control and 143 data transfer mechanisms for building a complete streaming system or 144 updating /integrating existing cache/CDN to support P2P streaming 145 delivery. 147 2. Terminology and concepts 149 Chunk: A chunk is a basic unit of partitioned streaming. Peers may 150 use a chunk as a unit of storage, advertisement and exchange among 151 peers [VoD]. Note that a streaming system may use different units for 152 advertisement and data exchange, using chunks during data exchange, 153 and a larger unit such as a set of chunks during advertisement. 155 Content Distribution Network (CDN): A CDN node refers to a network 156 entity that is deployed in the network (e.g., at the network edge or 157 data centers) to store content provided by the original servers, and 158 serves content to the clients located nearby topologically. 160 Client: A client refers to the service requester in client/server 161 computing paradigm. In this draft a client refers to a participant in 162 a P2P streaming system that only receives streaming content. In some 163 cases the node is not eligible to be a peer without enough computing 164 and storage capability is acting as a client. It can be viewed as a 165 specific kind of peer. 167 Live streaming: It refers to a scenario where all clients receive 168 streaming content for the same ongoing event. It is desired that the 169 lags between the play points of the clients and that of the streaming 170 source be small. 172 P2P cache: A P2P cache refers to a network entity that caches P2P 173 traffic in the network, and either transparently or explicitly as a 174 peer distributes content to other peers. 176 Peer: A peer refers to a participant in a P2P streaming system that 177 not only receives streaming content, but also stores and uploads 178 streaming content to other participants. 180 PPSP: The abbreviation of P2P streaming protocols. PPSP refer to the 181 key signaling protocols among various P2P streaming system components, 182 including the tracker and the peer. 184 Swarm: A swarm refers to a group of peers who exchange data to 185 distribute the same content (e.g. video/audio program, digital file, 186 etc) at a given time. 188 Tracker: A tracker refers to a directory server which maintains a 189 list of peers storing chunks for a specific channel or streaming file, 190 and answers queries from peers for peer lists. The tracker is a 191 logical component which can be centralized or distributed. 193 Video-on-demand (VoD): It refers to a scenario where different 194 clients may watch different parts of the same recorded media with 195 downloaded content. 197 3. Problem statement 199 The problems brought by proprietary signaling for P2P streaming 200 applications are listed as follows. 202 3.1. Difficulties for ISP in deploying P2P caches 204 Facing with many P2P streaming applications, ISPs are witnessing a 205 big traffic tension on their backbone and inter-networking points.P2P 206 cache is used to reduce the traffic by dynamically storing the 207 frequently accessed streaming content (maybe in chunk or in file 208 granularity). However, the cache nodes need to execute DPI (deep 209 packet inspection) for identifying different P2P streaming systems. 210 Multiple ever changing proprietary P2P streaming protocols require 211 the P2P cache updating its matching library constantly which 212 increases the operator's cost dramatically. 214 With PPSP, P2P cache can detect P2P streaming applications much 215 easier without needing to update its library. This reduces the ISP 216 workload to a large extent. Note that using standard PPSP won't hurt 217 current P2P streaming vendors : Firstly, the openness of signaling 218 interaction makes it easy to integrate them with ISP's caches for 219 better user experience, say, smaller delay of the play. Secondly, - 220 with PPSP, different applications use PPSP for signaling, but 221 implement something system specific on top of that. That is to say, 222 different P2P streaming systems compete on "on top" things, like 223 scheduling algorithms, which is independent of how the peers exchange 224 chunk availability. In other words, different systems can have quite 225 different scheduling algorithms with same tracker/peer protocol, , 226 which is easier to be open. 228 3.2. Difficulties in building open streaming delivery infrastructure 230 The future Internet is content-centric [DONA]because the vast 231 majority of current Internet usage (a "high 90% level of 232 traffic"[Van]) consists of data. Most of the content-centric works 233 are seeking for building an open global content delivery 234 infrastructure, where P2P streaming data delivery is going to account 235 for a large portion. However if current multiple proprietary 236 protocols continue to work, there will exist lots of specific and 237 independent systems to deliver vast of same streaming content. This 238 brings more burdens for identifying and sharing the same contents, 239 increases the storage, forwarding and maintenance cost in the 240 intermediate nodes for repeated content. This will definitely 241 increase the cost of streaming distribution and causes possible 242 congestion in the network. 244 Consider a case where source vendors cooperate with 3rd party CDN. 245 Such integration is already practiced by UUSee[UUSee], RayV[RayV] and 246 Forcetech[Forcetech]. The effect has been verified to improve the 247 total performance of P2P streaming (e.g., with lower latency) by 248 providing more stable "super peers" and reduce traffic for ISP 249 [CDN+P2P] [RFC 5693].However, there are substantial obstacles for CDN 250 nodes supporting proprietary P2P streaming protocols [HPTP]. Unlike 251 the Web where all kinds of the infrastructure devices have been 252 already equipped with standard HTTP protocol,an open CDN supporting 253 various P2P streaming applications need to understand and keep 254 updated on various protocols. Similar to the cache case, this 255 introduces complexity and deployment cost. 257 With PPSP, CDN nodes can be designed to inter-operate with other 258 devices by only standard protocols, reducing the case by case 259 negotiation between the source providers and CDN providers. Note 260 again that we just focus on the standard data availability 261 information interaction between tracker (maybe hosted by the source 262 provider) and CDN nodes, and among CDN nodes. The scheduling of data 263 among CDN nodes keeps intact. The interaction between CDN nodes and 264 user peers can be either client/server communication using HTTP or 265 peer to peer communication using PPSP. 267 3.3. Difficulties in mobile and wireless environment 269 Mobility and wireless are becoming increasingly important features in 270 future Internet deployments [GENI], [FIND]. It is predicted that by 271 the end of 2012, the number of mobile Internet users will surpass 272 that of fixed Internet users in China [Statistics]. Mobile streaming 273 has becoming a key offering [MobileTV]. In Korea the number of mobile 274 TV subscriber has reached seventeen millions, accounting for one 275 third of the mobile subscribers. During the 2008 Beijing Olympic 276 Games, more than one million users enjoyed mobile TV service. There 277 are more and more studies exploring P2P streaming in mobile and 278 wireless networks[Mobile Streaming1] [Mobile Streaming2] 280 However it's difficult to copy current P2P streaming protocols in 281 mobile and wireless networks. Current protocols are designed mainly 282 for fixed Internet. Although smart handsets are more eligible to be 283 peers with much better bandwidth and higher CPU frequency, larger 284 storage and memory than before, peer selection is more challenging 285 which needs more information to exchange during the tracker/peer and 286 peer/peer communications: First, in mobile and wireless networks, the 287 connections are unsteady, lower and costly(esp. in uplink). The 288 trackers and peers need more information, compared to fixed Internet, 289 like packet loss rate, peer battery status and processing capability 290 for peer selection. Note that not all mobile nodes are eligible to be 291 peers. The new-added information should help the tracker/peer to make 292 the decision. Second, current practices often use a "bitmap" message 293 to exchange chunk availability among peers/trackers. The message is 294 often of some kilobytes size and relatively frequent to exchange. In 295 the mobile networks, the bandwidth is scarce and a reasonable 296 optimization is to reduce the message size, which maybe requires a 297 new expression on "bitmap". Third, mobility issue. If a peer is 298 moving from one serving gateway (e.g., GGSN) to another, the IP 299 address will be changed. It may affect the on-going connection and 300 transmission between peers. Therefore such information should be 301 reported in time, which is not addressed in current practices. 303 PPSP should investigate these factors for a practical converged 304 network from the beginning of the design. 306 3.4. Difficulties for resource-constraint terminals to run multiple 307 background programs at the same time 309 Private protocols may require a terminal to install different 310 software for different applications. Note that for many client 311 software, even it's not used by the users right now, the background 312 program may be invoked to facilitate other peers for free data 313 delivery assistance. In other word, there will be multiple background 314 programs running at the same time. However it may be difficult to 315 invoke multiple programs in one resource constraint peer like mobile 316 handsets or set-top box. The limited CPU, storage and memory often 317 limit the total number of concurrent threads and processes. Taking 318 storage for example, according to [PPStream][UUSee][PPLive Design], 319 the buffer of each peer's hard disk contributed to the system is at 320 least 1GB. If each mobile peer, like iPhone (version 1) runs two such 321 background applications at the same time, the storage cannot be 322 shared for different applications and it will consume one fourth of 323 all its storage (8 GB), leaving other data with fewer storage. 325 With PPSP, there is possibility to share storage between different 326 applications with better resource utilization. The basic idea is that 327 different systems can share the buffer room( memory and storage) in 328 one terminal with same PPSP. Or else the buffer room is exclusive by 329 one application. Even the buffer is empty, it cannot be used by 330 another application. 332 4. PPSP:Standard peer to peer streaming protocols 334 The objective of this working group is to design PPSP, unified peer 335 to peer streaming protocols to address the problems discussed in the 336 preceding section. 338 There are basically two kinds of P2P streaming systems, pull-based 339 and push-based. 341 In pull-based P2P streaming systems, a centralized tracker or 342 distributed trackers maintains information about which peers are in 343 which swarms and answers the peers' query on such information with a 344 peer-list. After receiving the message, the peer can connect with the 345 candidates in a swarm, exchange its content availability in its 346 memory or storage (depending on it's real-time or VoD streaming) with 347 other peers and then retrieve for wanted streaming data. The swarm is 348 a mesh topology. Most of the current practices are belonging to this 349 genre. The advantages of pull-based mode are its robustness to the 350 peer churn and acceptable latency for a smooth play. 352 In push-based P2P streaming systems, there is a head node maintaining 353 the topology e.g., a tree. The peers in this topology share the same 354 interest on content. The signaling and data distribution are both 355 based on this topology. For one program or video file, the peer 356 queries the head node for its location to join and the head node 357 replies with a peer-list(maybe with recommended order). After 358 receiving this peer-list, the peer can connect with the candidates 359 for being a node in certain place of the topology and receive the 360 data along this topology without the need of exchanging content 361 availability with its siblings. In this sense the head node is acting 362 as the tracker. The push mode has the advantages of lower latency but 363 the topology is fragile to the peer churn. Few practical systems use 364 this mode. 366 A more practical mode is a hybrid pull-push mode where the peers 367 exchange content availability with its siblings for retrieving 368 unfounded data. 370 To sum up, in essence, there are two important entities in P2P 371 streaming, i.e., trackers and peers in P2P streaming systems. PPSP is 372 targeted to standardize the signaling protocols in this tracker-based 373 architectures for supporting both live and VoD streaming. 375 In live streaming, all peers are interested in the media coming from 376 an ongoing event, which means that all peers share nearly the same 377 streaming content at a given point of time. In live streaming, some 378 peers may store the live media for further distribution, which is 379 known as TSTV (time-shift TV), where the stored media are separated 380 into chunks and distributed in a VoD-like manner. 382 In VoD, different peers watch different parts of the recorded media 383 content during a past event. In this case, each peer keeps asking 384 other peers which media chunks are stored in which peers, and then 385 gets the required media from certain/selected peers. 387 In detail, PPSP designs a protocol for signaling between trackers and 388 peers (the PPSP "tracker protocol") and a signaling protocol for 389 communication among the peers (the PPSP "peer protocol") as shown in 390 Figure 1. The two protocols enable peers to receive streaming data 391 within the time constraints required by specific content items. The 392 tracker protocol handles the initial and periodic exchange of meta 393 information between trackers and peers, such as peer-list and content 394 information. The peer protocol controls the advertising and exchange 395 of media data between the peers. 397 Note that in the pull mode and hybrid pull-push mode, both tracker 398 protocol and peer protocol can be used; while in the push mode, only 399 tracker protocol is used. 401 What's more, existing protocols should be investigated and evaluated 402 for being reused or extended as the proposed protocols, e.g., HTTP. 403 Considering that there can be a large number of peers, the protocol 404 should also consider some lightweight (possibly binary) encoding. 406 +------------------------------------------------+ 407 | | 408 | +--------------------------------+ | 409 | | Tracker(Head Node) | | 410 | +--------------------------------+ | 411 | | ^ ^ | 412 |Tracker | | Tracker |Tracker | 413 |Protocol| | Procotol |Protocol | 414 | | | | | 415 | V | | | 416 | +---------+ Peer +---------+ | 417 | | Peer |<----------->| Peer | | 418 | +---------+ Protocol +---------+ | 419 | | ^ | 420 | | |Peer | 421 | | |Protocol | 422 | V | | 423 | +---------------+ | 424 | | Peer | | 425 | +---------------+ | 426 | | 427 | | 428 +------------------------------------------------+ 429 Figure 1 PPSP System Architecture 431 5. Use cases of PPSP 433 435 5.1. Worldwide provision of open P2P live streaming services 437 The cooperative vendors can easily expand the broadcasting scale with 438 PPSP. In figure 2 shows the case that vendor A broadcasts the program 439 with the help of vendor B and vendor C for a wider coverage. The 440 interaction between vendor A's tracker and vendor B and vendor C's 441 super-nodes (SN in short) can be normalized using tracker protocol; 442 and peer protocol can be used among SNs/peers spread in different 443 vendors. 445 +-------------------------------------------------------------------+ 446 | | 447 | +------------------+ | 448 | +------------>| A's Tracker |<----------+ | 449 | | +------------------+ | | 450 | Tracker| ^ ^ | | 451 | Protocol| Tracker| |Tracker |Tracker | 452 | | Protocol| |Protocol |Protocol | 453 | | | | | | 454 | | | | | | 455 | v v v v | 456 | +------+ Peer +------+ +------+ +------+ | 457 | | B's |<------->| B's | | C's | | C's | | 458 | | SN1 |Protocol | SN2 | | SN1 | | SN2 | | 459 | +------+ +------+ +------+ +------+ | 460 | ^ ^ ^ ^ | 461 | | | | | | 462 | | | Peer Protocol Peer Protocol| | | 463 | Peer | +-------------+ +--------------+ |Peer | 464 | Procotol| | | |protocol| 465 | | | | | | 466 | | | | | | 467 | | | | | | 468 | v v v v | 469 | +------+ Peer +------+ +---------+ Peer +---------+ | 470 | | A's |<------> | B's | |A's |<------> |C's | | 471 | | User1|Protocol | User2| | User1 |Protocol | User2 | | 472 | +------+ +------+ +---------+ +---------+ | 473 | | 474 +-------------------------------------------------------------------+ 475 Figure 2 Cooperative Vendors Interaction 477 5.2. CDN supporting P2P streaming 479 This scenario is similar to use case 1 except that the intermediate 480 SNs are replaced by 3rd party CDN surrogates with PPSP. The P2P 481 streaming vendors A and B can rent CDN surrogates to provide higher 482 QoS services for VIP users than services provides by only ordinary 483 peers. The interaction among these network entities are shown in 484 Figure 3. The CDN nodes talk with the different trackers and peers 485 with the uniform Tracker and peer protocols. Also it can also talk 486 with end users using HTTP for legacy equipments. The internal 487 interaction of CDN nodes can be executed by either original internal 488 protocol or new peer protocol. The latter is used when building a new 489 CDN system supporting streaming applications with low cost deploying 490 P2P delivery inside the network. 492 +-------------------------------------------------------------------+ 493 | | 494 | +-------------+ +--------------+ | 495 | +----->| A's Tracker | | B's Tracker |<---+ | 496 | | +-------------+ +--------------+ | | 497 | Tracker| ^ ^ ^ ^ | | 498 | Protocol| Tracker| |Tracker | |Tracker |Tracker | 499 | | Protocol| |Protocol| |Protocol |Protocol| 500 | | | | | | | | 501 | | | | | | | | 502 | v v | | v v | 503 | +------+ Peer +------+| | +------+Internal+------+ | 504 | | CDN |<------>| CDN || | | CDN |<-----> | CDN | | 505 | | Node1|Protocol| Node2|| | | Node3|Protocol| Node4| | 506 | +------+ +------+| | +------+ +------+ | 507 | ^ ^ | | ^ ^ | 508 | | | | | | | | 509 | | | Peer Protocol | | HTTP | | | 510 | Peer | +-------------+ | | +------+ | Peer | 511 | Procotol| | | | | Protocol |protocol| 512 | | | +-+ | | | | 513 | | | | | | | | 514 | | | | | | | | 515 | v v v v v v | 516 | +------+ Peer +------+ +---------+ Peer +---------+ | 517 | | A's |<------> | A's | |B's |<------> |B's | | 518 | | User1|Protocol | User2| | User3 |Protocol | User4 | | 519 | +------+ +------+ +---------+ +---------+ | 520 | | 521 +-------------------------------------------------------------------+ 522 Figure 3 CDN Supporting P2P Streaming 524 5.3. PPSP supporting cross-screen streaming in heterogeneous environment 526 In this scenario PC, Setbox/TV and mobile terminals from both fixed 527 network and mobile network share the content they store/cache. Peers 528 from heterogeneous networks 530 With PPSP Peers can identify the types of access networks, their load 531 /congestion information, peer abilities and get to know what content 532 other peers have (maybe with the conversion of the content 533 availability expression in different networks) even in different 534 network conditions as shown in Figure 4. These information will play 535 an important role on selecting suitable peers, e.g., a PC or STB node 536 is more likely to be selected to provide stable content for mobile 537 nodes; a mobile peer within a high-load base station is unlikely to 538 be selected, which will lead to higher load on the base station. 540 +-------------------------------------------------------------------+ 541 | | 542 | Tracker Protocol +---------+ Tracker Protocol | 543 | +-------------> | Tracker |<------------------+ | 544 | | +---------+ | | 545 | | ^ | | 546 | | | | | 547 | | | | | 548 | V | V | 549 | +------+ | +------------+ | 550 | | STB | Tracker Protocol |Mobile Phone| | 551 | +------+ | +------------+ | 552 | ^ | ^ | 553 | | | | | 554 | | | | | 555 | | V | | 556 | |Peer Protocol +---------+ Peer Protocol | | 557 | +-------------> | PC |<------------------+ | 558 | +---------+ | 559 | | 560 +-------------------------------------------------------------------+ 561 Figure 4 Heterogeneous P2P Streaming Interaction with PPSP 563 5.4. Supporting P2P streaming in cellular mobile network 565 In a cellular mobile environment like 3G or 4G, with the increase in 566 bandwidth and smart mobile terminal capabilities, P2P (including P2P 567 streaming) is easier to be realized than before. In a provincial 568 network of China Mobile, P2P has accounted for more than 30 569 percentage of the traffic, ranked second. 571 Note that the mobile terminals are not compulsorily to be peers. Here 572 they act as clients. Network peers who are deployed by the ISPs or 573 operators and mobile peers with WiFi connections are more likely to 574 be selected. For example, in 3GPP, there is a P2P CDS work item 575 working on the requirement of mobile operators to prefer use deployed 576 network-side equipments (e.g., serving gateways or GGSNs, one access 577 point from cellular mobile network to the Internet) to act as super- 578 peers when there are no enough eligible peers to realize P2P 579 streaming[P2P CDS]. Because they are deployed by the operators, the 580 stability and storage size are better guaranteed than ordinary peers. 582 Similar with case 5.3, PPSP tracker protocol will help to identify 583 and return the super-peers in the peer-list with preference. If 584 mobile terminals are not eligible to be peers, they can simply 585 receive data from these super-peers without contributing any data to 586 others. 588 5.5. Cache service supporting P2P streaming 590 As discussed in the section3, deploying cache nodes in the network 591 edges can greatly decrease the inter-network traffic and increase 592 user experience in streaming service. 594 With PPSP, the cache nodes can identify the P2P streaming genre even 595 it may include different applications. When a peer requests the 596 streaming data, cache detects the request and requests the frequent 597 visited content (or part of) to the original tracker as a normal peer. 598 The tracker replies with (outward) peers. After the cache connectes 599 with the peers, it can report what it cache to the provider's tracker 600 like a normal peer and serve other requesting peers inside to reduce 601 the cross-ISP traffic as shown in Figure 5. The cache nodes needn't 602 update their library when new applications supporting PPSP are 603 introduced, which enable the cache nodes spend less cost to support 604 more applications. 606 +----------------------------------------------------------------+ 607 | | 608 | 0:Tracker Protocol +---------+ | 609 | +----------------> | Tracker | | 610 | | +---------+ | 611 | | ^ | 612 | | | | 613 | | 2: | Tracker Protocol | 614 | | | | 615 | | | | 616 | | +---------|-------------------------------------| 617 | | | V | 618 | | | +---------+ | 619 | | +----------|---> | Cache |<-------------------+ | 620 | | | | +---------+ 1,4: Tracker/Peer| | 621 | | |3: Peer | Protocol | | 622 | | | Protocol | | | 623 | | | | | | 624 | | | | | | 625 | V V | V | 626 | +-----------+ | ISP Domain +------------+ | 627 | | Outward | | | Inside | | 628 | | Peer | | | Peer | | 629 | +-----------+ | +------------+ | 630 +----------------------------------------------------------------+ 632 Figure 5 Cache Service Supporting Streaming with PPSP 634 6. Security Considerations 636 PPSP will not attempt to provide a solution on security and copyright 637 issues like malicious content distribution, content pollution and DRM 638 for a general P2P streaming system. Instead PPSP security involves 639 the security problems related to PPSP protocols. The protocol 640 documents will contain a complete description on the security/privacy 641 issues relevant to any usage of PPSP. 643 6.1. Tracker Protocol 645 Malicious peers may issue denial of service attack to the trackers by 646 sending large amount of requests with tracker protocol. Distributed 647 trackers deployment may alleviate the problem. For protection against 648 denial of service attacks, standard security methods can be used. 650 Malicious peers may report fake information on behalf of other peers. 651 This can be avoided with peer authentication. 653 Malicious peers may report fake information about available content. 654 For this purpose, malicious peers can be reported to the tracker. 656 Malicious tracker, especially distributed version, can be very 657 harmful. 659 The malicious acting tracker may reply instead of the regular tracker 660 (man in the middle attack). To avoid this tracker authentication 661 could be used. 663 The malicious acting tracker may reply the peers with fake peer-list. 664 Peers may find they cannot find desired data with the fake peer-list. 666 6.2. Peer Protocol 668 Similar to the behavior in the tracker-peer interaction, malicious 669 peers may also create fake information on chunk availability and 670 exchange it with other peers. Some techniques to check the data 671 integrity (e.g., using checksum) may be useful for detecting the 672 attack. 674 7. Acknowledgments 676 We would like to acknowledge the following people who provided review, 677 feedback and suggestions to this document: M. Stiemerling;D. Bryan E. 678 Marocco; V. Gurbani; R. Even; H. Zhang; C. Schmidt;L. Xiao; C. 679 Williams; V. Pasual; D. Zhang; J. Lei. 681 8. References 683 [Cisco] Cisco Visual Networking Index: Forecast and Methodology, 684 2009-2014, 685 http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns7 686 05/ns827/white_paper_c11- 687 481360_ns827_Networking_Solutions_White_Paper.html 689 [PPLive] www.pplive.com 691 [VoD]Challenges, Design and Analysis of a Large-scale P2P-VoD 692 System,Yan Huang et al, Sigcomm08. 694 [CNN] www.cnn.com 696 [PPStream] www.ppstream.com 698 [UUSee] www.uusee.com 700 [CNTV] www.cntv.com 702 [Cirrus] labs.adobe.com/technologies/cirrus/ 704 [Akamai]Peer-to-Peer Systems, Rodrigo Rodrigues et al, Communications 705 of the ACM,Vol. 53 No. 10, Pages 72-82. 706 http://cacm.acm.org/magazines/2010/10/99498-peer-to-peer- 707 systems/fulltext. 709 [ChinaCache] 710 http://www.redorbit.com/news/technology/813722/rawflow_partners_with_ 711 chinacache_creating_asias_largest_p2p_powered_live/ 712 [ComCast]http://www.afterdawn.com/news/article.cfm/2008/05/20/comcast 713 _invests_in_p2p_streaming_startup 715 [DONA]A Data-Oriented (and Beyond) Network Architecture, T. Koponen 716 et al, Sigcomm 2007. 718 [Van] A New Way to Look at Networking,Van Jacobson, 719 http://video.google.com/videoplay?docid=-6972678839686672840 721 [RayV]http://www.rayv.com 723 [Forcetech]http://www.forcetech.net/english/solutions 725 [CDN+P2P]Efficient Large-scale Content Distribution with Combination 726 of CDN and P2P Networks, H. Jiang et al, International Journal of 727 Hybrid Information Technology, Vol.2, No.2, April, 2009. 729 [RFC 5693], Application-Layer Traffic Optimization (ALTO) Problem 730 Statement, E. Marocco et al, http://datatracker.ietf.org/doc/rfc5693/ 732 [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen 733 et al, IPTPS 2007. 735 [GENI] www.geni.net 737 [FIND] www.nets-find.net 739 [Statistics] http://labs.chinamobile.com/news/48283 741 [P2P CDS] 3GPP TR 22.906, Study on IMS based peer-to-peer content 742 distribution services,http://www.3gpp.org/ftp/Specs/html- 743 info/22906.htm 745 [Mobile Streaming1] Streaming To Mobile Users In A Peer-to-Peer 746 Network,Jeonghun Noh et al,MOBIMEDIA '09. 748 [Mobile Streaming2] A real-time peer-to-peer streaming system for 749 mobile networking environment,J. Peltotalo et al., "" in Proceedings 750 of the INFOCOM and Workshop on Mobile Video Delivery (MoVID '09), 751 April 2009. 753 [PPLive Design] Challenges, design and analysis of a large-scale p2p- 754 vod system, Y. Huang, T. Fu, D. Chiu, J. Lui, and C. Huang. ACM 755 SIGCOMM Computer Communication Review, 38(4):375-388, 2008. 757 Author's Addresses 759 Yunfei Zhang 761 China Mobile Communication Corporation 763 zhangyunfei@chinamobile.com 765 Ning Zong 767 Huawei Technologies Co., Ltd. 769 zongning@huawei.com 771 Gonzalo Camarillo 773 Ericsson 775 Gonzalo.Camarillo@ericsson.com 777 James Seng 779 PPLive 781 james.seng@pplive.com 783 Richard Yang 785 Yale University 787 yry@cs.yale.edu