idnits 2.17.1 draft-ietf-ppsp-problem-statement-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 25 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 594: '...he peer protocols SHOULD be as similar...' RFC 2119 keyword, line 600: '...ol and the peer protocol SHOULD enable...' RFC 2119 keyword, line 604: '...REQ-3: Each peer MUST have a unique ID...' RFC 2119 keyword, line 609: '...treaming content MUST be uniquely iden...' RFC 2119 keyword, line 618: '...treaming content MUST allow to be part...' (38 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2012) is 4435 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-ppsp-survey' is mentioned on line 632, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPSP Y. Zhang 2 Internet Draft China Mobile 3 N.Zong 4 HuaweiTech 5 G.Camarillo 6 Ericsson 7 R.Yang 8 Yale University 9 V. Pascual 10 Acme Packet 11 Intended status: Informational February 27, 2012 12 Expires: August 2012 14 Problem Statement and Requirements of Peer-to-Peer Streaming 15 Protocol (PPSP) 16 draft-ietf-ppsp-problem-statement-08.txt 18 Abstract 20 Peer-to-Peer (P2P for short) streaming systems show more and more 21 popularity in current Internet with proprietary protocols. This 22 document identifies problems of the proprietary protocols, proposes a 23 Peer to Peer Streaming Protocol (PPSP) including tracker and peer 24 signaling components, and discusses the scope, uses cases and 25 requirements of PPSP. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on August 27, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents carefully, 58 as they describe your rights and restrictions with respect to this 59 document. Code Components extracted from this document must include 60 Simplified BSD License text as described in Section 4.e of the Trust 61 Legal Provisions and are provided without warranty as described in 62 the Simplified BSD License. 64 Table of Contents 66 1. Introduction ................................................ 4 67 2. Terminology and concepts .................................... 5 68 3. Problem statement ........................................... 7 69 3.1. Traffic issue and difficulties for ISPs in deploying P2P 70 caches ...................................................... 7 71 3.2. Efficiency issue and difficulties in building open streaming 72 delivery infrastructure ..................................... 7 73 3.3. Extended applicability issue and difficulties in mobile and 74 wireless environment......................................... 8 75 4. PPSP: Standard peer to peer streaming protocols ............. 10 76 5. Use cases of PPSP ........................................... 12 77 5.1. Worldwide provision of live/VoD streaming .............. 12 78 5.2. PPSP supporting cross-screen streaming in heterogeneous 79 environment ................................................. 14 80 5.3. Cache service supporting P2P streaming ................. 15 81 6. Security Considerations ..................................... 17 82 7. Requirements of PPSP ........................................ 18 83 7.1. Basic Requirements ..................................... 18 84 7.2. PPSP Tracker Protocol Requirements ..................... 19 85 7.3. PPSP Peer Protocol Requirements ........................ 21 86 7.4. Security Requirements .................................. 22 87 8. IANA Considerations ......................................... 24 88 9. Acknowledgments ............................................. 25 89 10. Informative References ..................................... 26 91 1. Introduction 93 Streaming traffic is among the largest and fastest growing traffic on 94 the Internet [Cisco], where peer-to-peer (P2P) streaming contribute a 95 lot. With the advantage of high scalability and fault tolerance 96 against single point of failure, P2P streaming applications are able 97 to distribute large-scale, live and VoD streaming programs to 98 millions of audience with only a handful of servers. 100 What's more, along with the new players like CDN providers joining in 101 the effort of using P2P technologies in distributing their serving 102 streaming content, there are more and more various players in P2P 103 streaming ecosystem. 105 Given the increasing integration of P2P streaming into the global 106 content delivery infrastructure, the lack of an open, standard P2P 107 streaming signaling protocol suite becomes a major missing component 108 in the protocol stack. Almost all of existing systems use their 109 proprietary protocols. Multiple, similar but proprietary protocols 110 result in repetitious development efforts for new systems, and the 111 lock-in effects lead to substantial difficulties in their integration 112 with other players like CDN. For example, in the enhancement of 113 existing caches and CDN systems to support P2P streaming, proprietary 114 protocols may increase the complexity of the interaction with 115 different P2P streaming applications. 117 In this document we propose an open P2P Streaming Protocol, which is 118 defined as PPSP, to standardize signaling operations on two important 119 components, peer and tracker in P2P streaming systems for information 120 exchange. Note that using PPSP would not hurt current P2P streaming 121 vendors: Firstly, the openness of signaling interaction would make it 122 easy to integrate them with some infrastructural components like 123 ISP's caches or CDNs for better user experience, say, smaller delay 124 of the play. Secondly, different applications could use the same PPSP 125 for signaling, but implement system specific mechanisms on top of 126 that. That is to say, different P2P streaming systems compete on "on 127 top" things, like scheduling algorithms, which is independent of the 128 proposed protocols. 130 2. Terminology and concepts 132 Chunk: A chunk is a basic unit of data block organized in P2P 133 streaming for storage, scheduling, advertisement and exchange among 134 peers [VoD]. A chunk size varies from several KB to several MB in 135 different systems. In case of MB size chunk scenario, a sub-chunk 136 structure named piece is often defined to fit in a single transmitted 137 packet. A streaming system may use different granularities for 138 different usage, e.g., using chunks during data exchange, and using a 139 larger unit such as a set of chunks during advertisement. 141 Content Distribution Network (CDN): A CDN node refers to a network 142 entity that is deployed in the network (e.g., at the network edge or 143 data centers) to store content provided by the original servers, and 144 serves content to the clients located nearby topologically. 146 Client: A client refers to the service requester in client/server 147 computing paradigm. In this draft a client refers to a participant in 148 a P2P streaming system that only receives streaming content. In some 149 cases the node is not eligible to be a peer without enough computing 150 and storage capability is acting as a client. It can be viewed as a 151 specific kind of peer. 153 Live streaming: It refers to a scenario where all clients receive 154 streaming content for the same ongoing event. It is desired that the 155 lags between the play points of the clients and that of the streaming 156 source be small. 158 P2P cache: A P2P cache refers to a network entity that caches P2P 159 traffic in the network, and either transparently or explicitly as a 160 peer distributes content to other peers. 162 Peer: A peer refers to a participant in a P2P streaming system that 163 not only receives streaming content, but also stores and uploads 164 streaming content to other participants. 166 PPSP: The abbreviation of Peer-to-Peer Streaming Protocols. PPSP 167 refer to the key signaling protocols among various P2P streaming 168 system components, including the tracker and the peer. 170 Swarm: A swarm refers to a group of peers who exchange data to 171 distribute chunks of the same content (e.g. video/audio program, 172 digital file, etc) at a given time. 174 Tracker: A tracker refers to a directory server which maintains a 175 list of peers which participate in a specific video channel or in the 176 distribution of a streaming file, and answers queries from peers for 177 peer lists. The tracker is a logical component which can be 178 centralized or distributed. 180 Video-on-demand (VoD): It refers to a scenario where different 181 clients may watch different parts of the same recorded media with 182 downloaded content. 184 Peer list: A list of peers which are in a same swarm maintained by 185 the tracker. A peer can fetch the peer list of a swarm from either 186 tracker or other peers to know which peers have the required 187 streaming content. 189 Peer ID: An identifier of a peer such that other peers or tracker can 190 refer the ID for the peer. 192 Swarm ID: An identifier of a swarm containing a group of peers 193 sharing a same streaming content. 195 Chunk ID: An identifier of a chunk in a streaming content. 197 3. Problem statement 199 The problems imposed by proprietary protocols for P2P streaming 200 applications are listed as follows. 202 3.1. Traffic issue and difficulties for ISPs 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 caches are used for ISPs to reduce the traffic by dynamically storing 207 the frequently accessed streaming content (in chunk or in file 208 granularity). 210 However, unlike the Web where all kinds of the infrastructure devices 211 have been already equipped with standard HTTP protocol, cache systems 212 have to build a matching library to identify different P2P streaming 213 protocols firstly. Multiple ever changing proprietary protocols 214 require the cache system updating its matching library constantly. 215 This increases the operator's cost dramatically. 217 With PPSP, P2P caches needn't learn new proprietary protocols any 218 longer, which would reduce the ISP workload much. 220 3.2. Efficiency issue and difficulties in building open streaming 221 delivery infrastructure 223 Another problem for P2P streaming applications is the efficiency 224 issue. P2P streaming is often criticized by longer delays (e.g., 225 startup delay, seek delay and channel switch delay). Hybrid CDN/P2P 226 is a good means to solve this problem for operators [Hybrid CDN P2P]. 228 In such design, CDN takes two roles: one is for media streaming 229 server and the other is for P2P tracker. Consider a CDN vendor 230 serving for various P2P streaming, similar to the P2P cache issue in 231 Section 3.1, proprietary P2P streaming protocols introduce 232 interaction complexity between the peer and tracker, and increase 233 deployment cost of CDN nodes. 235 With PPSP, CDN nodes acting as the P2P tracker can be designed to 236 inter-operate with other devices by only standard protocols, reducing 237 the case by case negotiation. On the other side, the interface 238 between edged CDN nodes and user peers could be either via something 239 like traditional HTTP, or via PPSP peer protocol. 241 3.3. Extended applicability issue and difficulties in mobile and 242 wireless environment 244 Mobility and wireless are becoming increasingly important in today's 245 Internet, where streaming service is a major usage. In Korea the 246 number of mobile TV subscriber has reached seventeen million, 247 accounting for one third of the mobile subscribers. There are 248 multiple prior studies exploring P2P streaming in mobile and wireless 249 networks [Mobile Streaming1] [Mobile Streaming2]. 251 However it's difficult to copy current P2P streaming protocols (even 252 we suppose we can re-use the proprietary ones) in mobile and wireless 253 networks. Current protocols are designed mainly for fixed Internet. 254 Although smart handsets are more eligible to be peers with much 255 higher bandwidth and CPU frequency, larger storage and memory than 256 before, peer selection becomes more challenging which needs more 257 information to exchange during the tracker/peer and peer/peer 258 communications: 260 First, the connections are unsteady, lower rate, and costly in terms 261 of energy consumption and transmission (esp. in uplink). The trackers 262 and peers may need more information like packet loss rate, peer 263 battery status and processing capability for peer selection. 265 Second, current practices often use a "bitmap" message to exchange 266 chunk availability among peers/trackers. The message is often of some 267 kilobytes size and exchanged relatively frequently, say, some seconds. 268 In a scarce bandwidth resource environment, a reasonable optimization 269 is to reduce the message size, which may require alternative methods 270 for expressing and distributing bitmap information. 272 Third, when a peer is moving and if the IP address changes, the on- 273 going connection and transmission between peers may be affected. Such 274 information should be reported in time. 276 Fourth, for a resource constraint peer like mobile handsets or set- 277 top boxes (STB), the limited resource and the requirements for 278 installing various applications form big conflicts. On one side, the 279 limited CPU, storage and memory often limit the total number of 280 concurrent threads and processes. One the other side, the proprietary 281 protocols require the user to install many different applications for 282 different usage, for instance, some applications have rich resources 283 on TV series or movies while others may offer rich broadcasting 284 sports program. What's worse, for many P2P applications, even they 285 are not used by the users right now, the background program may be 286 invoked to facilitate other peers for free data delivery assistance. 287 That is to say, there will be multiple background programs running at 288 the same time. But it may be difficult to invoke multiple programs in 289 such a resource constraint peer. PPSP should investigate these 290 factors and help to reduce the resource consumption in a converged 291 network. 293 4. PPSP: Standard peer to peer streaming protocols 295 The objective of the PPSP working group is to design a unified peer- 296 to-peer streaming protocol (PPSP) to address the problems discussed 297 in the preceding sections. 299 There are basically two kinds of P2P streaming systems, pull-based 300 and push-based. 302 In pull-based P2P streaming systems, a centralized tracker or 303 distributed trackers maintains information about which peers are in 304 which swarms and answers the peers' query on such information with a 305 peer-list. After receiving the message, the peer can connect with the 306 candidates in a swarm, exchange its content availability in its 307 memory or storage (depending on it is real-time or VoD streaming) 308 with other peers and then retrieve the wanted streaming data. The 309 swarm is a mesh topology. Most of the current practices belong to 310 this genre. The advantages of pull-based mode are its robustness to 311 the peer churn and acceptable latency for a smooth play. Most 312 commercial systems either live streaming and VoD use this mode. 314 In push-based P2P streaming systems, there is a head node maintaining 315 the topology, e.g., a tree. The head node acts similar to a tracker. 316 The peers in this topology share the same interest on content. The 317 signaling and data distribution are both based on this topology. For 318 one program or video file, the peer queries the head node by offline 319 or pre-set head node address information for its location to join and 320 the head node replies with a peer-list(potentially in a recommended 321 order). After receiving this peer-list, the peer can connect with the 322 candidates for being a node in certain place of the topology and 323 receive the data along this topology without the need of exchanging 324 content availability with its siblings, as done in pull-based mode. 325 In this sense the head node is acting as the tracker in the pull- 326 based mode. The push mode has the advantages of lower latency but the 327 topology is fragile to the peer churn and is hard to deal with the 328 VoD scenario. This makes it less robust in practical running. Few 329 commercially deployed systems use this mode. 331 PPSP is targeted to standardize signaling protocols for tracker-based 332 architectures feasible for both modes above that support either live 333 or offline streaming. 335 The PPSP design includes a protocol for signaling between trackers 336 and peers (the PPSP "tracker protocol") and a signaling protocol for 337 communication among the peers (the PPSP "peer protocol") as shown in 338 Figure 1.The two protocols enable peers to receive streaming data 339 within the time constraints required by specific content items. The 340 tracker protocol handles the initial and periodic exchange of meta 341 information between trackers and peers, such as peer-list and content 342 information. The peer protocol controls the advertising and exchange 343 of media data between the peers. 345 Note that in the pull mode, both tracker protocol and peer protocol 346 can be used; while in the push mode, only tracker protocol is used. 348 +------------------------------------------------+ 349 | | 350 | +--------------------------------+ | 351 | | Tracker(Head Node) | | 352 | +--------------------------------+ | 353 | | ^ ^ | 354 |Tracker | | Tracker |Tracker | 355 |Protocol| | Procotol |Protocol | 356 | | | | | 357 | V | | | 358 | +---------+ Peer +---------+ | 359 | | Peer |<----------->| Peer | | 360 | +---------+ Protocol +---------+ | 361 | | ^ | 362 | | |Peer | 363 | | |Protocol | 364 | V | | 365 | +---------------+ | 366 | | Peer | | 367 | +---------------+ | 368 | | 369 | | 370 +------------------------------------------------+ 371 Figure 1 PPSP System Architecture 373 5. Use cases of PPSP 375 5.1. Worldwide provision of live/VoD streaming 377 The content provider can easily expand the broadcasting/VoD scale to 378 utilize the cooperative content providers' distribution networks or 379 third party CDN networks with PPSP. 381 Figure 2 shows the case that provider A broadcasts the program with 382 the help of provider B and C for a wider coverage. Without PPSP, when 383 users in B or C's domain (outside A's main serving zone) requests A's 384 programs, the returned peer-list may include few local peers, which 385 may decrease the user viewing experience. With PPSP more local 386 resources from cooperative vendors may be utilized. The content 387 providers often deploy in-network peers called super-nodes (SN for 388 short) with better stability and higher storage and bandwidth for 389 better QoS. With tracker protocol, vendor A's tracker can returns 390 user request with vendor B and vendor C's SNs in the peer-list. Users 391 in B and C's domain can exchange data (availability) with these SNs 392 using peer protocol for better QoS. In this way vendor B and vendor 393 C's SNs resources are shared with vendor A and vendor A expands its 394 serving scale with acceptable QoS. 396 +-------------------------------------------------------------------+ 397 | | 398 | +------------------+ | 399 | +------------>| A's Tracker |<----------+ | 400 | | +------------------+ | | 401 | Tracker| ^ ^ | | 402 | Protocol| Tracker| |Tracker |Tracker | 403 | | Protocol| |Protocol |Protocol | 404 | | | | | | 405 | | | | | | 406 | v v v v | 407 | +------+ Peer +------+ +------+ +------+ | 408 | | B's |<------->| B's | | C's | | C's | | 409 | | SN1 |Protocol | SN2 | | SN1 | | SN2 | | 410 | +------+ +------+ +------+ +------+ | 411 | ^ ^ ^ ^ | 412 | | | | | | 413 | | | Peer Protocol Peer Protocol| | | 414 | Peer | +-------------+ +--------------+ |Peer | 415 | Procotol| | | |protocol| 416 | | | | | | 417 | | | | | | 418 | | | | | | 419 | v v v v | 420 | +------+ Peer +------+ +---------+ Peer +---------+ | 421 | | A's |<------> | B's | |A's |<------> |C's | | 422 | | User1|Protocol | User2| | User1 |Protocol | User2 | | 423 | +------+ +------+ +---------+ +---------+ | 424 | | 425 +-------------------------------------------------------------------+ 426 Figure 2 Cooperative Vendors Interaction 428 Figure 3 is similar to Figure 2 except that the intermediate SNs are 429 replaced by 3rd party CDN surrogates with PPSP. The P2P streaming 430 vendors A and B can rent CDN surrogates to provide higher QoS for VIP 431 users. The CDN nodes talk with the different vendors (including the 432 peers inside) with the uniform protocols. For users who use browser 433 equipped with HTTP, scalable streaming is also achieved. The internal 434 interaction of CDN nodes can be executed by either existing protocol 435 or peer protocol. The latter is used when building a new CDN system 436 supporting streaming applications with lower cost. 438 +-------------------------------------------------------------------+ 439 | | 440 | +-------------+ +--------------+ | 441 | +----->| A's Tracker | | B's Tracker |<---+ | 442 | | +-------------+ +--------------+ | | 443 | Tracker| ^ ^ ^ ^ | | 444 | Protocol| Tracker| |Tracker | |Tracker |Tracker | 445 | | Protocol| |Protocol| |Protocol |Protocol| 446 | | | | | | | | 447 | | | | | | | | 448 | v v | | v v | 449 | +------+ Peer +------+| | +------+Internal+------+ | 450 | | CDN |<------>| CDN || | | CDN |<-----> | CDN | | 451 | | Node1|Protocol| Node2|| | | Node3|Protocol| Node4| | 452 | +------+ +------+| | +------+ +------+ | 453 | ^ ^ | | ^ ^ | 454 | | | | | | | | 455 | | | Peer Protocol | | HTTP | | | 456 | Peer | +-------------+ | | +------+ | Peer | 457 | Procotol| | | | | Protocol |protocol| 458 | | | +-+ | | | | 459 | | | | | | | | 460 | | | | | | | | 461 | v v v v v v | 462 | +------+ Peer +------+ +---------+ Peer +---------+ | 463 | | A's |<------> | A's | |B's |<------> |B's | | 464 | | User1|Protocol | User2| | User3 |Protocol | User4 | | 465 | +------+ +------+ +---------+ +---------+ | 466 | | 467 +-------------------------------------------------------------------+ 468 Figure 3 CDN Supporting P2P Streaming 470 5.2. PPSP supporting cross-screen streaming in heterogeneous environment 472 In this scenario PC, STB/TV and mobile terminals from both fixed 473 network and mobile/wireless network share the streaming content. With 474 PPSP, peers can identify the types of access networks, average load, 475 peer abilities and get to know what content other peers have 476 (potentially with the conversion of the content availability 477 expression in different networks) even in different network 478 conditions as shown in Figure 4. 480 These information will play an important role on selecting suitable 481 peers, e.g., a PC or STB is more likely to be selected to provide 482 stable content for mobile nodes; a mobile peer within a high-load 483 base station is unlikely to be selected, which may lead to higher 484 load on the base station. 486 +-------------------------------------------------------------------+ 487 | | 488 | Tracker Protocol +---------+ Tracker Protocol | 489 | +-------------> | Tracker |<------------------+ | 490 | | +---------+ | | 491 | | ^ | | 492 | | | | | 493 | | | | | 494 | V | V | 495 | +------+ | +------------+ | 496 | | STB | Tracker Protocol |Mobile Phone| | 497 | +------+ | +------------+ | 498 | ^ | ^ | 499 | | | | | 500 | | | | | 501 | | V | | 502 | |Peer Protocol +---------+ Peer Protocol | | 503 | +-------------> | PC |<------------------+ | 504 | +---------+ | 505 | | 506 +-------------------------------------------------------------------+ 507 Figure 4 Heterogeneous P2P Streaming Interaction with PPSP 509 5.3. Cache service supporting P2P streaming 511 In Figure 5, when peers request the P2P streaming data, the cache 512 nodes intercept the requests and ask for the frequently visited 513 content (or part of) on behalf of the user peers. To do this, it 514 requests peer-list to the tracker and the tracker replies with 515 (outward) peers in the peer-list. After the cache nodes exchange data 516 with these peers, it can report what it cache to the tracker like a 517 normal peer and serve other requesting peers inside. This operation 518 greatly decreases the inter-network traffic and increase user 519 experience in P2P streaming services for an ISP. 521 The cache nodes needn't update their library when new applications 522 supporting PPSP are introduced, which enable the cache nodes spend 523 less cost to support more applications. 525 +----------------------------------------------------------------+ 526 | | 527 | 0:Tracker Protocol +---------+ | 528 | +----------------> | Tracker | | 529 | | +---------+ | 530 | | ^ | 531 | | | | 532 | | 2: | Tracker Protocol | 533 | | | | 534 | | | | 535 | | +---------|-------------------------------------| 536 | | | V | 537 | | | +---------+ | 538 | | +----------|---> | Cache |<-------------------+ | 539 | | | | +---------+ 1,4: Tracker/Peer| | 540 | | |3: Peer | Protocol | | 541 | | | Protocol | | | 542 | | | | | | 543 | | | | | | 544 | V V | V | 545 | +-----------+ | ISP Domain +------------+ | 546 | | Outward | | | Inside | | 547 | | Peer | | | Peer | | 548 | +-----------+ | +------------+ | 549 +----------------------------------------------------------------+ 551 Figure 5 Cache Service Supporting Streaming with PPSP 553 6. Security Considerations 555 This document discusses the problem statement around Peer-to-Peer 556 streaming protocols without specifying the protocols. The protocol 557 specification is deferred to other documents under development in the 558 PPSP working group. However we believe it is important for the reader 559 to understand areas of security caused by the P2P nature of the 560 proposed solution. The main issue is the usage of un-trusted entities 561 (peers) for service provisioning. 563 Malicious peers may, for example: 565 - Issue denial of service (DOS) attacks to the trackers by sending 566 large amount of requests with the tracker protocol; 568 - Issue fake information on behalf of other peers; 570 - Issue fake information about available content; 572 - Issue fake information about chunk availability; 574 Malicious peers/trackers may, for example: 576 - Issue reply instead of the regular tracker (man in the middle 577 attack). 579 The PPSP protocol specifications, e.g., the tracker protocol and the 580 peer protocol, will document the expected threats and how they will 581 be mitigated for each protocol, but also considerations on threats 582 and mitigations when combining both protocols in an application. This 583 will include privacy of the users, protection of the content 584 distribution, but not protection of the content by Digital Rights 585 Management (DRM). 587 7. Requirements of PPSP 589 This section enumerates the requirements for the PPSP, which should 590 be considered when designing PPSP. 592 7.1. Basic Requirements 594 PPSP.REQ-1: The tracker and the peer protocols SHOULD be as similar 595 as possible, in terms of design, message formats and flows. 597 It is desirable that the peer protocol would be an extension to the 598 tracker protocol by adding a few message types, or vice versa. 600 PPSP.REQ-2: The tracker protocol and the peer protocol SHOULD enable 601 peers to receive streaming content within the required time 602 constraints, i.e., fulfill streaming feature. 604 PPSP.REQ-3: Each peer MUST have a unique ID (i.e. peer ID) in a swarm. 606 It's a basic requirement for a peer to be uniquely identified in a 607 swarm that other peers or tracker can refer to the peer by ID. 609 PPSP.REQ-4: The streaming content MUST be uniquely identified by a 610 swarm ID. 612 A swarm refers to a group of peers sharing the same streaming content. 613 A swarm ID uniquely identifies a swarm. The swarm ID can be used in 614 two cases: 1) a peer requests the tracker for the peer list indexed 615 by a swarm ID; 2) a peer tells the tracker about the swarms it 616 belongs to. 618 PPSP.REQ-5: The streaming content MUST allow to be partitioned into 619 chunks. 621 A key characteristic of P2P streaming system is allowing the data 622 fetching from different peers concurrently. Therefore, the whole 623 streaming content must allow to be partitioned into small pieces or 624 chunks for transmission between peers. 626 PPSP.REQ-6: Each chunk MUST have a unique ID (i.e. chunk ID) in the 627 swarm. 629 Each chunk must have a unique ID in the swarm such as the peer can 630 understand which chunks are stored in which peers and which chunks 631 are requested by other peers. An example for generating the chunk ID 632 is the buffer map approach [I-D.ietf-ppsp-survey]. 634 PPSP.REQ-7: The tracker protocol and peer protocol are recommended to 635 be carried over TCP (or UDP, when delivery requirements cannot be met 636 by TCP). 638 PPSP.REQ-8: The tracker and peer protocol together MUST facilitate 639 acceptable QoS (e.g. low startup delay, low channel/content switching 640 time and minimal end-to-end delay) for both on-demand and live 641 streaming, even for very popular content. The tracker and peer 642 protocol do not include the algorithm required for scalable 643 streaming. However, the tracker and peer protocol SHALL NOT restrict 644 or place limits on any such algorithm. 646 There are basic QoS requirements for streaming system. Setup time to 647 receive a new streaming channel or to switch between channels should 648 be reasonable small. End to end delay (time between content 649 generation, e.g. camera and content consumption, e.g. user side 650 monitor) will become critical in case of live streaming. Especially 651 in provisioning of sports events, end to end delay of 1 minute and 652 more are not acceptable. 654 For instance, the tracker and peer protocols can support carrying QoS 655 related parameters (e.g. video quality, delay requirements) together 656 with the priorities of these parameters, and QoS situation (e.g., 657 performance, available uplink bandwidth) of content providing peers. 659 There are also some other possible mechanisms, e.g. addition of super 660 peers, in-network storage, request of alternative peer addresses, and 661 the usage of QoS information for an advanced peer selection. 663 7.2. PPSP Tracker Protocol Requirements 665 The tracker protocol defines how the peers report and request 666 information to/from the tracker and how the tracker replies to the 667 requests. The tracker discovery and the possible communication 668 between trackers are out of the scope of tracker protocol. 670 PPSP.TP.REQ-1: The tracker MUST implement the tracker protocol for 671 receiving queries and periodical peer status reports/updates from the 672 peers and for sending the corresponding replies. 674 PPSP.TP.REQ-2: The peer MUST implement the tracker protocol for 675 sending queries and periodical peer status reports/updates to the 676 tracker and receiving the corresponding replies. 678 PPSP.TP.REQ-3: The tracker request message MUST allow the requesting 679 peer to solicit the peer list from the tracker with respect to a 680 specific swarm ID. 682 The tracker request message may also include the requesting peer's 683 preference parameter, e.g. preferred number of peers in the peer 684 list, or preferred downloading bandwidth. The track will then be 685 able to select an appropriate set of peers for the requesting peer 686 according to the preference. 688 PPSP.TP.REQ-4: The tracker reply message MUST allow the tracker to 689 offer the peer list to the requesting peer with respect of a specific 690 swarm ID. 692 PPSP.TP.REQ-5: The tracker SHOULD support generating the peer list 693 with the help of traffic optimization services, e.g. ALTO [I-D.ietf- 694 alto-protocol]. 696 PPSP.TP.REQ-6: The peer status report/update MUST have the ability to 697 inform the tracker about the peer's activity in the swarm. 699 PPSP.TP.REQ-7: The chunk availability information of the peer SHOULD 700 be reported to tracker when tracker needs such information to steer 701 peer selection. The chunk information MUST at least contain the 702 chunk ID. 704 PPSP.TP.REQ-8: The chunk availability information between peer and 705 tracker MUST be as expressed as compactly as possible. 707 The peers may report CHUNK AVAILABILTY DIGEST information (i.e., 708 compact expression of chunk availability) to the tracker when 709 possible to decrease the bandwidth consumption for messages in 710 bandwidth constraint environment like mobile network. For example, 711 if a peer has a bitmap like 111111...1(100 continuous 1)xxx..., the 712 100 continuous "1" can be expressed by one byte with seven bits 713 representing 100 and one bit representing "1".In this example, 100- 714 8=92 bits are saved. Considering the frequency of exchange of CHUNK 715 AVAILBILITY and the fact that many bitmaps have quite a long length 716 of continuous "1" or "0", such compression makes sense. 718 PPSP.TP.REQ-9: The status of the peer SHOULD be reported to the 719 tracker when tracker needs such information to steer peer selection. 721 For example, peer status can be online time, physical link status 722 including DSL/WIFI/etc, battery status, processing capability, and 723 other capabilities of the peer. Therefore, the tracker is able to 724 select better candidate peers for streaming. 726 7.3. PPSP Peer Protocol Requirements 728 The peer protocol defines how the peers advertise streaming content 729 availability and exchange status with each other. The peer protocol 730 also defines the requests and responses of the chunks among the 731 peers. The first task for this WG will be to decide which signaling 732 and media transfer protocols will be used. The WG will consider 733 existing protocols and, if needed, identify potential extensions to 734 these protocols. 736 PPSP.PP.REQ-1: The streaming content availability request message 737 MUST allow the peer to solicit the chunk information from other peers 738 in the peer list. The chunk information MUST at least contain the 739 chunk ID. This chunk availability information MUST NOT be passed on 740 to other peer, unless validated (e.g. prevent hearsay and DoS). 742 PPSP.PP.REQ-2: The streaming content availability reply message MUST 743 allow the peer to offer the information of the chunks in its content 744 buffer. The chunk information MUST at least contain the chunk ID. 746 PPSP.PP.REQ-3: The streaming content availability request message 747 SHOULD allow the peer to solicit an additional list of peers to that 748 received from the tracker - with the same swarm ID. The reply 749 message MUST contain swarm-membership information of the peers that 750 have explicitly indicated they are part of the swarm, verifiable by 751 the receiver. This additional list of peers MUST only contain peers 752 which have been checked to be valid and online recently (e.g. prevent 753 hearsay and DoS). 755 It is possible that a peer may need additional peers for certain 756 streaming content. Therefore, it is allowed that the peer 757 communicates with the peers in the current peer list to obtain an 758 additional list of peers in the same swarm. 760 PPSP.PP.REQ-4: Streaming content availability update message among 761 the peers MUST be supported by peer protocol. In the push based 762 model, where peers advocate their own chunk availability proactively, 763 the content availability request message described in PP.REQ-1 is not 764 needed. The peer protocol MUST implement either pull-based, push- 765 based or both. 767 Due to the dynamic change of the buffered streaming content in each 768 peer and the frequent join/leave of peers in the swarm, the streaming 769 content availability among a peer's neighbors (i.e. the peers known 770 to a peer by getting the peer lists from either tracker or peers) 771 always changes and thus requires being updated on time. This update 772 should be done at least on demand. For example, when a peer requires 773 finding more peers with certain chunks, it sends a message to some 774 other peers in the swarm for streaming content availability update. 775 Alternatively, each peer in the swarm can advertise its streaming 776 content availability to some other peers periodically. However, the 777 detailed mechanisms for this update such as how far to spread such 778 update message, how often to send this update message, etc should 779 leave to peer algorithms, rather than protocol concerns. 781 PPSP.PP.REQ-5: The chunk availability information between peers MUST 782 be as expressed as compactly as possible. 784 In PP.REQ-1/2/4, the peers may exchange CHUNK AVAILABILTY DIGEST 785 information (i.e. compact expression of chunk availability) to with 786 other peers when possible to decrease the bandwidth consumption for 787 messages in bandwidth constraint environment like mobile network. 789 PPSP.PP.REQ-6: The peer status report/update SHOULD be advertised 790 among the peers to reflect the status of the peer. 792 Peer status information should be advertised among the peers via the 793 peer status report/update message. For example, peer status can be 794 online time, physical link status including DSL/WIFI/etc, battery 795 status, processing capability, and other capabilities of the peer. 796 With this information, a peer can select more appropriate peers for 797 streaming. 799 PPSP.PP.REQ-7: The peers MUST implement the peer protocol for chunk 800 data (not availability information) requests and responses among the 801 peers before the streaming content is transmitted. 803 7.4. Security Requirements 805 PPSP.SEC.REQ-1: PPSP MUST support closed swarms, where the peers are 806 authenticated. 808 This ensures that only the authenticated users can access the 809 original media in the P2P streaming system. This can be achieved by 810 security mechanisms such as user authentication and/or key management 811 scheme. 813 PPSP.SEC.REQ-2: Confidentiality of the streaming content in PPSP 814 SHOULD be supported and the corresponding key management scheme 815 SHOULD scale well in P2P streaming system. 817 PPSP.SEC.REQ-3: PPSP MUST provide an option to encrypt the data 818 exchange among the PPSP entities. 820 PPSP.SEC.REQ-4: PPSP MUST have mechanisms to limit potential damage 821 caused by malfunctioning and badly behaving peers in the P2P 822 streaming system. 824 Such an attack will degrade the quality of the rendered media at the 825 receiver. For example, in a P2P live video streaming system a 826 polluter can introduce corrupted chunks. Each receiver integrates 827 into its playback stream the polluted chunks it receives from its 828 other neighbors. Since the peers forwards chunks to other peers, the 829 polluted content can potentially spread through much of the P2P 830 streaming network. 832 PPSP.SEC.REQ-5: PPSP SHOULD support identifying badly behaving peers, 833 and exclude or reject them from the P2P streaming system. 835 PPSP.SEC.REQ-6: PPSP MUST prevent peers from DoS attacks which will 836 exhaust the P2P streaming system's available resource. 838 Given the prevalence of DoS attacks in the Internet, it is important 839 to realize that a similar threat could exist in a large-scale 840 streaming system where attackers are capable of consuming a lot of 841 resources with just a small amount of effort. 843 PPSP.SEC.REQ-7: PPSP SHOULD be robust, i.e., when centralized tracker 844 fails the P2P streaming system SHOULD still work by supporting 845 distributed trackers. 847 PPSP.SEC.REQ-8: Existing P2P security mechanisms SHOULD be re-used as 848 much as possible in PPSP, to avoid developing new security 849 mechanisms. 851 PPSP.SEC.REQ-9: Integrity of the streaming content in PPSP MUST be 852 supported to provide a peer with the possibility to identify 853 inauthentic media content (undesirable modified by other entities 854 rather than its genuine source). The corresponding checksum 855 distribution and verification scheme SHOULD scale well in P2P 856 streaming system and be robust against distrustful trackers/peers. 858 8. IANA Considerations 860 This document has no actions for IANA. 862 9. Acknowledgments 864 Thank you to J.Seng for contribution to many sections of this draft. 865 Thank you to C. Williams and L. Xiao for contributions to PPSP 866 requirements section. 868 We would like to acknowledge the following people who provided review, 869 feedback and suggestions to this document: M. Stiemerling; C. Schmidt; 870 D. Bryan; E. Marocco; V. Gurbani; R. Even; H. Zhang; V. Pasual; D. 871 Zhang; J. Lei; Y.Gu; H.Song; X.Jiang; J.Seedorf; D.Saumitra; A.Rahman; 872 L.Deng; J.Pouwelse; A.Bakker and W.Eddy. 874 This document was prepared using 2-Word-v2.0.template.dot. 876 10. Informative References 878 [Cisco] Cisco Visual Networking Index: Forecast and Methodology, 879 2009-2014, 880 http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ 881 ns827/white_paper_c11-481360_ns827_Networking_Solutions_White_Paper.html 883 [VoD] Yan Huang et al, Challenges,"Design and Analysis of a Large- 884 scale P2P-VoD System", Sigcomm08. 886 [Mobile Streaming1] Streaming to Mobile Users in a Peer-to-Peer 887 Network, Jeonghun Noh et al, MOBIMEDIA '09. 889 [Mobile Streaming2] J.Peltotaloet al.,"A real-time Peer-to-Peer 890 streaming system for mobile networking environment",in 891 Proceedings of the INFOCOM and Workshop on Mobile Video 892 Delivery (MoVID '09), April 2009. 894 [I-D.ietf-alto-protocol]Alimi, R., Penno, R., and Y. Yang, "ALTO 895 Protocol", draft-ietf-alto-protocol-10 (work in progress), 896 October 2011. 898 [Hybrid CDN P2P]D. Xu, S. Kulkarni, C. Rosenberg, and H. Chai, 899 "Analysis of a CDN-P2P hybrid architecture for cost- 900 effective streaming media distribution," Springer 901 Multimedia Systems, vol.11, no.4, pp.383-399, 2006. 903 [I-D.ietf-ppsp-survey]Gu, Y., Zong, N., Zhang, H., Zhang, Y., Lei, J., 904 Camarillo, G., Liu, Y., Montuno, D., and X. Lei, "Survey 905 of P2P Streaming Applications", draft-ietf-ppsp-survey-02 906 (work in progress), July 2011. 908 Authors' Addresses 910 Yunfei Zhang 911 China Mobile Communication Corporation 912 zhangyunfei@chinamobile.com 914 NingZong 915 Huawei Technologies Co., Ltd. 916 zongning@huawei.com 918 Gonzalo Camarillo 919 Ericsson 920 Gonzalo.Camarillo@ericsson.com 922 Richard Yang 923 Yale University 924 yry@cs.yale.edu 926 Victor Pascual 927 Acme packet 928 Anabel Segura 10, Madrid 28108, Spain 929 Vpascual@acmepacket.com