idnits 2.17.1 draft-ietf-ppsp-problem-statement-01.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 8 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 228 has weird spacing: '...mantics betwe...' -- The document date (January 16, 2011) is 4847 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Survey' is mentioned on line 89, but not defined == Missing Reference: 'VoD' is mentioned on line 139, but not defined == Missing Reference: 'PPstream' is mentioned on line 99, but not defined == Missing Reference: 'ChinaCache' is mentioned on line 106, but not defined == Missing Reference: 'ComCast' is mentioned on line 107, but not defined == Missing Reference: 'DONA' is mentioned on line 201, but not defined == Missing Reference: 'RayV' is mentioned on line 233, but not defined == Missing Reference: 'Forcetech' is mentioned on line 233, but not defined == Missing Reference: 'HTPT' is mentioned on line 239, but not defined == Missing Reference: 'FIND' is mentioned on line 254, but not defined == Missing Reference: 'MobileTV' is mentioned on line 260, but not defined == Unused Reference: 'PPStream' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'Van' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'HPTP' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'P2P CDS' is defined on line 647, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 17 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: July 16, 2011 January 16, 2011 13 Problem Statement of P2P Streaming Protocol (PPSP) 14 draft-ietf-ppsp-problem-statement-01 16 Abstract 18 P2P streaming systems show more and more popularity in current 19 Internet with proprietary protocols. This document identifies 20 problems of the proprietary protocols, proposes standard signaling 21 protocols called PPSP and discusses the scope and use case of PPSP. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on July 16, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction ................................................. 4 58 2. Terminology and concepts ..................................... 6 59 3. Problem statement ............................................ 7 60 3.1. ISP's difficulties in deploying P2P caches .............. 7 61 3.2. Difficulties in building open streaming delivery 62 infrastructure ............................................... 7 63 3.3. Difficulties in mobile and wireless environment...........8 64 3.4. Terminal physical resource starvation ................... 9 65 4. PPSP:Standard peer to peer streaming protocols .............. 10 66 5. Use cases of PPSP ........................................... 13 67 5.1. Worldwide provision of open P2P live streaming services. 13 68 5.2. CDN supporting P2P streaming ........................... 13 69 5.3. PPSP supporting cross-screen streaming in heterogeneous 70 environment ................................................. 14 71 5.4. Supporting P2P streaming in cellular mobile network..... 15 72 5.5. Cache service supporting P2P streaming ................. 16 73 6. Security Considerations ..................................... 17 74 6.1. Tracker Protocol ....................................... 17 75 6.2. Peer Protocol .......................................... 17 76 7. Acknowledgements ............................................ 18 77 8. References .................................................. 19 79 1. Introduction 81 Streaming traffic is among the fastest growing traffic on the 82 Internet. As Cisco Visual Network Traffic index measured, video 83 streaming already generates the largest volume of Internet traffic in 84 the year of 2010, and the percentage is expected to rise to as high 85 as 91% of the total Internet traffic by 2014[Cisco]. 87 There are two basic architectures for delivering streaming traffic on 88 the global Internet: the client-server paradigm and the peer to peer 89 (P2P) paradigm [Survey].The basic advantage of the P2P paradigm is 90 its scalability and fault tolerance against failures of centralized 91 infrastructures. As an example, PPLive [PPLive], one of the largest 92 P2P streaming vendors, is able to distribute large-scale, live 93 streaming programs such as the CCTV Spring Festival Gala to more than 94 3 million users with only a handful of servers. It can also deliver 95 VoD streaming to a scale of some hundred of thousands simultaneous 96 users using the same structure and similar protocols[VoD]. The effect 97 of P2P technologies is also well demonstrated in delivering real and 98 VoD streaming effectively in current practice like CNN [CNN] PPstream 99 [PPstream],UUSee [UUSee]and CNTV[CNTV]. The latest release of Adobe 100 Flash, a major platform of streaming distribution in the Internet, 101 has also introduced Cirrus [Cirrus], a peer assisted data exchange 102 mode. Almost all these systems use their proprietary signaling 103 protocols and standard data delivery protocols (like UDP and TCP). 105 What's more, along with the new players like CDN vendors (e.g.,Akamai 106 [Akamai], ChinaCache[ChinaCache]) and ISPs(e.g., ComCast 107 [ComCast])joining in the P2P streaming delivery game, the P2P 108 streaming ecosystem is becoming more complex with participants from 109 the source, infrastructure side, edge delivery even to the terminals. 111 Given the above increasing integration of P2P streaming into the 112 global content delivery infrastructure, the lacking of an open, 113 standard P2P streaming signaling protocol suite becomes a major 114 missing component in the Internet protocol stack. Multiple, similar 115 but proprietary signaling protocols result in repetitious development 116 efforts for new systems, and the lock-in effects lead to substantial 117 difficulties in the integration. For example, in the enhancement of 118 existing caches and CDN systems to support P2P streaming, the open 119 protocols will dynamically reduce the complexity of the interaction 120 with different P2P streaming applications. 122 In this document we propose an open P2P streaming protocol named PPSP, 123 to standardize signaling operations on two important components, peer 124 and tracker for information exchange. The problems of proprietary 125 signaling protocols and benefit of PPSP are explained further in 126 section 3. 128 PPSP will serve as an enabling technology, building on the 129 development experiences of existing P2P streaming systems. Its design 130 will allow it to integrate with IETF protocols on distributed 131 resource location, traffic localization, and streaming control and 132 data transfer mechanisms for building a complete streaming system or 133 a streaming delivery infrastructure. 135 2. Terminology and concepts 137 Chunk: A chunk is a basic unit of partitioned streaming. Peers may 138 use a chunk as a unit of storage, advertisement and exchange among 139 peers [VoD]. Note that a streaming system may use different units for 140 advertisement and data exchange, using chunks during data exchange, 141 and a larger unit such as a set of chunks during advertisement. 143 Content Distribution Network (CDN): A CDN node refers to a network 144 entity that is deployed in the network (e.g., at the network edge or 145 data centers) to store content provided by the original servers, and 146 serves content to the clients located nearby topologically. 148 Live streaming: It refers to a scenario where all clients receive 149 streaming content for the same ongoing event. It is desired that the 150 lags between the play points of the clients and that of the streaming 151 source be small. 153 P2P cache: A P2P cache refers to a network entity that caches P2P 154 traffic in the network, and either transparently or explicitly as a 155 peer distributes content to other peers. 157 Peer: A peer refers to a participant in a P2P streaming system that 158 not only receives streaming content, but also stores and uploads 159 streaming content to other participants. 161 PPSP: The abbreviation of P2P streaming protocols. PPSP refer to the 162 key signaling protocols among various P2P streaming system components, 163 including the tracker and the peer. 165 Swarm: A swarm refers to a group of clients (i.e., peers) who exchang 166 data to distribute the same content (e.g. video/audio program, 167 digital file, etc) at a given time. 169 Tracker: A tracker refers to a directory server which maintains a 170 list of peers storing chunks for a specific channel or streaming file, 171 and answers queries from peers for peer lists. The tracker is a logic 172 component which can be centralized or distributed. 174 Video-on-demand (VoD): It refers to a scenario where different 175 clients may watch different parts of the same recorded media content 176 during a past event. 178 3. Problem statement 180 Let's take a look what problems proprietary signaling brings out for 181 P2P streaming applications. 183 3.1. ISP's difficulties in deploying P2P caches 185 Facing with many P2P streaming applications, ISPs are witnessing a 186 big traffic tension on their backbone and inter-networking ports.P2P 187 cache is used to reduce the traffic by dynamically storing the 188 frequently accessed streaming content (maybe in chunk or in file 189 granularity). It's often deployed in the edge or inter-networking 190 places of the network. However, the cache nodes need to execute DPI 191 (deep packet inspection) for identifying different P2P streaming 192 systems. Multiple ever changing proprietary P2P streaming protocols 193 require the P2P cache updating its matching library constantly which 194 increases the operator's cost dramatically. 196 With PPSP, P2P cache can detect P2P streaming applications much 197 easier. This reduces the ISP workload to a large extent. 199 3.2. Difficulties in building open streaming delivery infrastructure 201 The future Internet is content-centric [CCN][DONA]because the vast 202 majority of current Internet usage (a "high 90% level of 203 traffic"[Van]) consists of data. Most of the content-centric works 204 are seeking for building an open global content delivery 205 infrastructure. In content-centric networks there is no doubt that 206 P2P streaming data is going to account for a large portion. If 207 current multiple proprietary protocols continue to work, there will 208 exist lots of specific and independent systems to deliver vast 209 streaming content. This brings more burdens for identifying and 210 sharing the same contents, increases the storage, forwarding and 211 maintenance cost in the intermediate nodes for repeated content and 212 for the same content, many on-the-way data spread over the Internet. 213 All these will definitely increase the cost of streaming distribution 214 and causes possible congestion in the network. 216 In an open P2P streaming delivery infrastructure, It must involve 217 different participants in the distribution chain ranging from the 218 source (or current P2P streaming vendors) , infrastructure (e.g, CDN) 219 and delivery side(caches or terminal peers). 221 Let's first consider a simplest open P2P streaming environment where 222 different source vendors spread in different regions cooperatively 223 deliver a broadcasting event. Suppose PPLive cooperatively broadcasts 224 live Chinese spring festival gala for American Chinese with Pando 225 networks. At a first sight, this is reasonable because PPlive has 226 relatively few users in USA and Utilizing Pando's peer resources can 227 help to realize efficient streaming delivery. However, different 228 messages and interaction semantics between the two systems is a big 229 challenge for the cooperative delivery. 231 Consider a more complex case where source vendors cooperate with CDN 232 providers. Such integration is already practiced by UUSee[UUSee], 233 RayV[RayV] and Forcetech[Forcetech]. The effect of the involvement of 234 infrastructure devices such as CDN nodes has been verified to improve 235 the total performance of P2P streaming (e.g., with lower latency) by 236 providing more stable "super peers" and reduce traffic in ISP network 237 [CDN+P2P] [RFC 5693].However, there are substantial obstacles in 238 deploying infrastructure nodes supporting proprietary P2P streaming 239 protocols [HTPT]. Unlike the Web who has already equipped with the 240 standard HTTP protocol and all kinds of the infrastructure devices 241 support the protocol, in order to support P2P streaming, the 242 infrastructure devices need to understand and keep updated with 243 various protocols to take part in the delivery. Similar to the cache 244 case, this introduces complexity and deployment cost for the 245 infrastructure devices. 247 With PPSP, CDN nodes can be designed to inter-operate with only the 248 standard protocols, reducing the case by case negotiation between the 249 source providers and multiple CDN providers. 251 3.3. Difficulties in mobile and wireless environment 253 Mobility and wireless are becoming increasingly important features to 254 support in future Internet deployments [GENI], [FIND]. Currently 255 there are more and more mobile and wireless Internet users. It is 256 predicted that by the end of 2012, the number of mobile Internet 257 users will surpass that of fixed Internet users in China [Statistics]. 259 Along with this trend, mobile streaming is becoming a key offering 260 [MobileTV]. In Korea the number of mobile TV subscriber has reached 261 seventeen millions, accounting for one third of the mobile 262 subscribers. During the 2008 Beijing Olympic Games, more than one 263 million users enjoyed mobile TV service. 265 Although mobile handsets are more eligible to be peers with much 266 better bandwidth and higher CPU frequency, larger storage and memory 267 than several years ago, mobile and wireless peers may face bigger 268 challenges for supporting P2P streaming with unsteady and relatively 269 lower (esp. in uplink) network connections, less steady power than 270 PCs. And what are worse, current protocols are designed mainly for 271 the fixed Internet and do not address these challenges. 273 In what kinds of network dynamical conditions, what kinds of mobile 274 nodes can act as peers should be investigated to reflect in the 275 standard protocols from the beginning of the design. 277 3.4. Terminal physical resource starvation 279 Private protocols may require a terminal to install multiple 280 different software at the same time. For example a user installs CBox 281 for CCTV programs [CNTV], and PPLive for Japanese and Korean movies 282 [PPLive]. However it may be difficult to install multiple clients in 283 one resource constraint peer like mobile handsets or Pads. The 284 limited CPU, storage and memory often limit the total number of 285 installed applications as well as concurrent threads and processes. 286 Note that for many client software, even it's not used by the users 287 right now, the daemon may be invoked to facilitate other peers for 288 free data delivery assistance. 290 Standard protocols reduce the complexity of coexisting multiple 291 closed systems and create possibilities to use one client software 292 accommodating different systems. 294 4. PPSP:Standard peer to peer streaming protocols 296 The objective of this working group is to design PPSP, unified peer 297 to peer streaming protocols to address the problems discussed in the 298 preceding section. 300 There are basically two kinds of P2P streaming systems, pull-based 301 and push-based. In pull-based P2P streaming systems, a centralized 302 tracker or distributed trackers maintains information about which 303 peers are in which swarms and answers the peers' query on such 304 information with a peer-list. After receiving the message, the peer 305 can connect with the candidates in a swarm, exchange its content 306 availability in its memory or storage (depending on it's real-time or 307 VoD streaming) with other peers and then retrieve for wanted 308 streaming data. The swarm is a mesh topology. Most of the current 309 practices are belonging to this genre. The advantages of pull-based 310 mode are its robustness to the peer churn and acceptable latency for 311 a smooth play. On the other hand, in push-based P2P streaming 312 systems, there is a head node maintaining the topology e.g., a tree. 313 The peers in this topology share the same interest on content. The 314 signaling and data distribution are both based on this topology. For 315 one program or video file, the peer queries the head node for its 316 location to join and the head node replies with a peer-list(maybe 317 with recommended connection order). After receiving this peer-list, 318 the peer can connect with the candidates for being a node in certain 319 place of the topology and receive the data along this topology 320 without the need of exchanging content availability with its siblings. 321 In this sense the head node is acting as the tracker. The push mode 322 has the advantages of lower latency but the topology is fragile to 323 the peer churn. Few practical systems use this mode. A more practical 324 mode is a hybrid pull-push mode where the peers exchange content 325 availability with its siblings for retrieving unfounded data. 327 As discussed above, in essence, there are two important entities in 328 P2P streaming, i.e., trackers and peers. PPSP is targeted to 329 standardize the signaling protocols in tracker-based architectures 330 for supporting both live and VoD streaming. 332 In live streaming, all peers are interested in the media coming from 333 an ongoing event, which means that all peers share nearly the same 334 streaming content at a given point of time. In live streaming, some 335 peers may store the live media for further distribution, which is 336 known as TSTV (time-shift TV), where the stored media are separated 337 into chunks and distributed in a VoD-like manner. 339 In VoD, different peers watch different parts of the recorded media 340 content during a past event. In this case, each peer keeps asking 341 other peers which media chunks are stored in which peers, and then 342 gets the required media from certain/selected peers. 344 In detail, PPSP designs a protocol for signaling between trackers and 345 peers (the PPSP "tracker protocol") and a signaling protocol for 346 communication among the peers (the PPSP "peer protocol") as shown in 347 Figure 1. The two protocols enable peers to receive streaming data 348 within the time constraints required by specific content items. The 349 tracker protocol handles the initial and periodic exchange of meta 350 information between trackers and peers, such as peer-list and content 351 information. The peer protocol controls the advertising and exchange 352 of media data between the peers. 354 Note that in the pull mode and hybrid pull-push mode, both tracker 355 protocol and peer protocol can be used; while in the push mode, only 356 tracker protocol is used. 358 What's more, existing protocols should be investigated and evaluated 359 for being reused or extended as the protocols among peers, e.g., HTTP. 360 Considering that there can be a large number of peers, the protocol 361 should consider some lightweight (possibly binary) encoding. 363 +------------------------------------------------+ 364 | | 365 | +--------------------------------+ | 366 | | Tracker(Head Node) | | 367 | +--------------------------------+ | 368 | | ^ ^ | 369 |Tracker | | Tracker |Tracker | 370 |Protocol| | Procotol |Protocol | 371 | | | | | 372 | V | | | 373 | +---------+ Peer +---------+ | 374 | | Peer |<----------->| Peer | | 375 | +---------+ Protocol +---------+ | 376 | | ^ | 377 | | |Peer | 378 | | |Protocol | 379 | V | | 380 | +---------------+ | 381 | | Peer | | 382 | +---------------+ | 383 | | 384 | | 385 +------------------------------------------------+ 386 Figure 1 PPSP System Architecture 388 5. Use cases of PPSP 390 5.1. Worldwide provision of open P2P live streaming services 392 The cooperative vendors can easily expand the broadcasting scale with 393 PPSP. In figure 2 the interactions between vendor A's tracker and vendor 394 B and vendor C's super-nodes (SN in short) can be normalized using 395 tracker protocol; and peer protocol can be used among SNs/peers spread 396 in different vendors. 398 +-------------------------------------------------------------------+ 399 | | 400 | +------------------+ | 401 | +------------>| A's Tracker |<----------+ | 402 | | +------------------+ | | 403 | Tracker| ^ ^ | | 404 | Protocol| Tracker| |Tracker |Tracker | 405 | | Protocol| |Protocol |Protocol | 406 | | | | | | 407 | | | | | | 408 | v v v v | 409 | +------+ Peer +------+ +------+ +------+ | 410 | | B's |<------->| B's | | C's | | C's | | 411 | | SN1 |Protocol | SN2 | | SN1 | | SN2 | | 412 | +------+ +------+ +------+ +------+ | 413 | ^ ^ ^ ^ | 414 | | | | | | 415 | | | Peer Protocol Peer Protocol| | | 416 | Peer | +-------------+ +--------------+ |Peer | 417 | Procotol| | | |protocol| 418 | | | | | | 419 | | | | | | 420 | | | | | | 421 | v v v v | 422 | +------+ Peer +------+ +---------+ Peer +---------+ | 423 | | A's |<------> | B's | |A's |<------> |C's | | 424 | | User1|Protocol | User2| | User1 |Protocol | User2 | | 425 | +------+ +------+ +---------+ +---------+ | 426 | | 427 +-------------------------------------------------------------------+ 428 Figure 2 Cooperative Vendors Interactions 430 5.2. CDN supporting P2P streaming 432 This scenario is similar to use case 1 but it involves more kinds of 433 participants: besides P2P streaming vendors, non-P2P streaming 434 vendors and CDN providers are also involved in the delivery. 436 The CDN surrogates can act as the super-nodes of different P2P 437 streaming vendors with PPSP. The interactions among these network 438 entities are the same as shown in Figure 2. The P2P streaming vendors 439 can rent CDN resources to provide better QoS assured services for VIP 440 users than services provides by only ordinary peers. 442 Another case is that the CDN providers offer P2P streaming 443 distribution with PPSP. This often occurs for an operator or CDN 444 vendor to build a new CDN system supporting streaming applications 445 with low cost. This service is very useful for a small streaming 446 provider who has no much money to distribute its stream worldwide. It 447 can also be used by an operator to launch self-operating streaming 448 service from the beginning. 450 5.3. PPSP supporting cross-screen streaming in heterogeneous environment 452 In this scenario PC, Setbox/TV and mobile terminals from both fixed 453 network and mobile network work together sharing the content they 454 store/cache and finishing the streaming delivery. 456 Using PPSP, peers can identify the types of networks, peer abilities 457 and and get to know what content other peers have (maybe with the 458 conversion of the content availability expression in different 459 networks) even in different network conditions as shown in Figure 3. 460 This will play an important role on the sharing among heterogeneous 461 peers. 463 +-------------------------------------------------------------------+ 464 | | 465 | Tracker Protocol +---------+ Tracker Protocol | 466 | +-------------> | Tracker |<------------------+ | 467 | | +---------+ | | 468 | | ^ | | 469 | | | | | 470 | | | | | 471 | V | V | 472 | +------+ | +------------+ | 473 | | STB | Tracker Protocol |Mobile Phone| | 474 | +------+ | +------------+ | 475 | ^ | ^ | 476 | | | | | 477 | | | | | 478 | | V | | 479 | |Peer Protocol +---------+ Peer Protocol | | 480 | +-------------> | PC |<------------------+ | 481 | +---------+ | 482 | | 483 +-------------------------------------------------------------------+ 484 Figure 3 Heterogeneous P2P Streaming Interactions with PPSP 486 5.4. Supporting P2P streaming in cellular mobile network 488 In a cellular mobile environment like 3G or 4G, with the increase in 489 bandwidth and smart mobile terminal capabilities, P2P streaming is 490 easier to be realized than before. Note that the mobile terminals are 491 not compulsorily to be peers. Network peers who are deployed by the 492 ISPs or operators and mobile peers with WiFi connections are more 493 often selected. For example, in 3GPP, there is a P2P CDS work item on 494 the requirement of mobile operators to prefer use deployed network- 495 side equipments (e.g., serving gateways or GGSNs, one access point 496 from cellular mobile network to the Internet) to act as super-peers 497 when there are no enough eligible peers to realize P2P streaming[P2P 498 CDS]. Because they are deployed by the operators, the stability and 499 storage size are better guaranteed than ordinary peers. 501 In this case the PPSP tracker protocol will identify the network 502 types and dynamics as well as the terminal types and return super- 503 peers in the peer-list to these super-peers and normal mobile peers. 504 If mobile terminals are not eligible to be peers, they can simply 505 receive data from these super-peers without contributing any data to 506 others. 508 5.5. Cache service supporting P2P streaming 510 As discussed in the section3, deploying cache nodes in the network 511 edges can greatly decrease the inter-network traffic and increase 512 user experience in streaming service. 514 With PPSP, the cache nodes can identify the P2P streaming genre even 515 it may include different applications, cache the frequent visited 516 content (or part of) and report what they cache to the provider's 517 tracker like a normal peer and serve other requesting peers in 518 sharing data as shown in Figure 4. The cache nodes needn't update 519 their library when new applications are introduced, which enable the 520 cache nods spend less cost to support more applications. 522 +-------------------------------------------------------------------+ 523 | | 524 | Tracker Protocol +---------+ Tracker Protocol | 525 | +-------------> | Tracker |<--------------------+ | 526 | | +---------+ | | 527 | | | | 528 | | | | 529 | | | | 530 | V V | 531 | +-----------+ Peer Protocol +------------+ | 532 | | Cache |<------------------------------->| Peer | | 533 | +-----------+ +------------+ | 534 +-------------------------------------------------------------------+ 536 Figure 4 Cache Service Supporting Streaming with PPSP 538 6. Security Considerations 540 PPSP will not attempt to provide a solution on security and copyright 541 issues like malicious content distribution, content pollution and DRM 542 for a general P2P streaming system. Instead PPSP security 543 considerations involve the security problems related to PPSP 544 protocols. 546 6.1. Tracker Protocol 548 Malicious peers may issue denial of service attack to the trackers by 549 sending large amount of requests with tracker protocol. Distributed 550 trackers deployment may alleviate the problem. 552 On the other hand, malicious peers may report fake information (e.g., 553 cheating trackers and other peers by claiming itself owning some 554 unexisting data). 556 So it may be optional in some cases to realize authentication to the 557 peers before accepting the request for the tracker. But this may add 558 up the tracker's workload on authentication. 560 In the above discussion tracker is trustful. Things are worse when 561 the malicious peer acts as part of the distributed trackers, who is 562 untrustful with much possibility. The malicious acting tracker may 563 reply the peers with fake peer-list. Peers may find they cannot find 564 desired data with the fake peer-list. 566 6.2. Peer Protocol 568 Similar to the behavior in the tracker-peer interaction, malicious 569 peers may also create fake information on chunk availability and 570 exchange it with other peers. Some techniques to check the data 571 integrity (e.g., using checksum) may be useful for detecting the data. 572 But this part is out of scope of PPSP. 574 The protocol documents will contain a complete description on the 575 security/privacy issues relevant to any usage of PPSP. 577 7. Acknowledgements 579 We would like to acknowledge the following people who provided review, 580 feedback and suggestions to this document: M. Stiemerling;D. Bryan E. 581 Marocco; V. Gurbani; R. Even; H. Zhang; C. Schmidt;L. Xiao; C. 582 Williams; V. Pasual; D. Zhang; J. Lei. 584 8. References 586 [Cisco] Cisco Visual Networking Index: Forecast and Methodology, 587 2009-2014, 588 http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns7 589 05/ns827/white_paper_c11- 590 481360_ns827_Networking_Solutions_White_Paper.html 592 [PPLive] www.pplive.com 594 [VoD]Challenges, Design and Analysis of a Large-scale P2P-VoD 595 System,Yan Huang et al, Sigcomm08. 597 [CNN] www.cnn.com 599 [PPStream] www.ppstream.com 601 [UUSee] www.uusee.com 603 [CNTV] www.cntv.com 605 [Cirrus] labs.adobe.com/technologies/cirrus/ 607 [Akamai] Understanding hybrid CDN-P2P: why limelight needs its own 608 Red Swoosh, C. Huang et al,Proceedings of the 18th International 609 Workshop on Network and Operating Systems Support for Digital Audio 610 and Video, May 28-30, 2008, Braunschweig, Germany. 612 [ChinaCache]www.chinacache.com 614 [ComCast]http://www.afterdawn.com/news/article.cfm/2008/05/20/comcast 615 _invests_in_p2p_streaming_startup 617 [CCN] Content-Centric Networking,V. Jacobson, 618 https://wiki.tools.isoc.org/@api/deki/files/2634//=1.vj.isoc.mar10.pd 619 f 621 [DONA]A Data-Oriented (and Beyond) Network Architecture, T. Koponen 622 et al, Sigcomm 2007. 624 [Van] A New Way to Look at Networking,Van Jacobson, 625 http://video.google.com/videoplay?docid=-6972678839686672840 627 [RayV]www.rayv.com 629 [Forcetech]http://www.forcetech.net/english/solutions 631 [CDN+P2P]Efficient Large-scale Content Distribution with Combination 632 of CDN and P2P Networks, H. Jiang et al, International Journal of 633 Hybrid Information Technology, Vol.2, No.2, April, 2009. 635 [RFC 5693], Application-Layer Traffic Optimization (ALTO) Problem 636 Statement, E. Marocco et al, http://datatracker.ietf.org/doc/rfc5693/ 638 [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen 639 et al, IPTPS 2007. 641 [GENI] www.geni.net 643 [FIND]www.nets-find.net 645 [Statistics] http://labs.chinamobile.com/news/48283 647 [P2P CDS] 3GPP TR 22.906, Study on IMS based peer-to-peer content 648 distribution services,http://www.3gpp.org/ftp/Specs/html- 649 info/22906.htm 651 Author's Addresses 653 Yunfei Zhang 655 China Mobile Communication Corporation 657 zhangyunfei@chinamobile.com 659 Ning Zong 661 Huawei Technologies Co., Ltd. 663 zongning@huawei.com 665 Gonzalo Camarillo 667 Ericsson 668 Gonzalo.Camarillo@ericsson.com 670 James Seng 672 PPLive 674 james.seng@pplive.com 676 Richard Yang 678 Yale University 680 yry@cs.yale.edu