idnits 2.17.1 draft-ietf-ppsp-problem-statement-10.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 8 instances of too long lines in the document, the longest one being 9 characters 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 595: '...he peer protocol SHOULD allow peers to...' RFC 2119 keyword, line 598: '...REQ-2: Each peer MUST have a unique ID...' RFC 2119 keyword, line 603: '...treaming content MUST be uniquely iden...' RFC 2119 keyword, line 612: '...treaming content MUST allow to be part...' RFC 2119 keyword, line 620: '...EQ-5: Each chunk MUST have a unique ID...' (37 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2012) is 4237 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PPLive' is mentioned on line 316, but not defined == Unused Reference: 'PPTV' is defined on line 920, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ppsp-survey-02 == Outdated reference: A later version (-12) exists of draft-ietf-ppsp-peer-protocol-02 Summary: 2 errors (**), 0 flaws (~~), 6 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 6 Intended status: Informational September 19, 2012 7 Expires: March 2013 9 Problem Statement and Requirements of Peer-to-Peer Streaming 10 Protocol (PPSP) 11 draft-ietf-ppsp-problem-statement-10.txt 13 Abstract 15 Peer-to-Peer (P2P for short) streaming systems show more and more 16 popularity in current Internet with proprietary protocols. This 17 document identifies problems of the proprietary protocols, proposes a 18 Peer to Peer Streaming Protocol (PPSP) including tracker and peer 19 signaling components, and discusses the scope, requirements and uses 20 cases of PPSP. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on March 18, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ................................................ 4 63 2. Terminology and concepts. .................................... 5 64 3. Problem statement ........................................... 7 65 3.1. Heterogeneous P2P traffic and P2P caches deployment ..... 7 66 3.2. Latency efficiency difficulties ......................... 7 67 3.3. Extended applicability in mobile and wireless environment 7 68 4. PPSP: Standard peer to peer streaming protocols .............. 9 69 4.1. Tracker protocol candidates discussion and design issues .9 70 4.2. Peer protocol candidates discussion and design issues . 10 71 5. Use cases of PPSP .......................................... 11 72 5.1. Worldwide provision of live/VoD streaming .............. 11 73 5.2. Cross-screen streaming ................................. 13 74 5.3. Cache service supporting P2P streaming ................. 14 75 5.4. Proxy service supporting P2P streaming ................. 15 76 5.4.1. Home Networking Scenario .......................... 15 77 5.4.2. Browser-based HTTP Streaming ...................... 16 78 6. Requirements of PPSP ........................................ 17 79 6.1. Basic Requirements ..................................... 17 80 6.2. PPSP Tracker Protocol Requirements ..................... 18 81 6.3. PPSP Peer Protocol Requirements ........................ 19 82 7. Security Considerations .................................... 21 83 8. IANA Considerations ........................................ 23 84 9. Acknowledgments ............................................ 23 85 10. Informative References. .................................... 24 87 1. Introduction 89 Streaming traffic is among the largest and fastest growing traffic on 90 the Internet [Cisco], where peer-to-peer (P2P) streaming contribute 91 substantially. With the advantage of high scalability and fault 92 tolerance against single point of failure, P2P streaming applications 93 are able to distribute large-scale, live and video on demand (VoD) 94 streaming programs to millions of audience with only a handful of 95 servers. What's more, along with the new players like CDN providers 96 joining in the effort of using P2P technologies in distributing their 97 serving streaming content, there are more and more various players in 98 P2P streaming ecosystem. 100 Given the increasing integration of P2P streaming into the global 101 content delivery infrastructure, the lack of an open, standard P2P 102 streaming signaling protocol suite becomes a major missing component 103 in the protocol stack. Almost all of existing systems use their 104 proprietary protocols. Multiple, similar but proprietary protocols 105 result in repetitious development efforts for new systems, and the 106 lock-in effects lead to substantial difficulties in their integration 107 with other players like CDN. For example, in the enhancement of 108 existing caches and CDN systems to support P2P streaming, proprietary 109 protocols may increase the complexity of the interaction with 110 different P2P streaming applications. 112 In this document we propose an open P2P Streaming Protocol, which is 113 defined as PPSP, to standardize signaling operations in P2P streaming 114 systems to solve the above problems. 116 2. Terminology and concepts 118 Chunk: A chunk is a basic unit of data block organized in P2P 119 streaming for storage, scheduling, advertisement and exchange among 120 peers [VoD]. A chunk size varies from several KBs to several MBs in 121 different systems. In case of MBs size chunk scenario, a sub-chunk 122 structure named piece is often defined to fit in a single transmitted 123 packet. A streaming system may use different granularities for 124 different usage, e.g., using chunks during data exchange, and using a 125 larger unit such as a set of chunks during advertisement. 127 Chunk ID: The identifier of a chunk in a content stream. 129 Client: A client in general refers to the service requester in 130 client/server computing paradigm. In this draft a client also refers 131 to a participant in a P2P streaming system that only receives 132 streaming content. In some cases, a node not having enough computing 133 and storage capabilities will act as a client. Such node can be 134 viewed as a specific type of peer. 136 Content Distribution Network (CDN): A CDN is a collection of nodes 137 that are deployed, in general, at the network edge like Points of 138 Presence (POP) or Data Centers (DC) and that store content provided 139 by the original content servers. Typically, CDN nodes serve content 140 to the clients located nearby topologically. 142 Live streaming: It refers to a scenario where all clients receive 143 streaming content for the same ongoing event. It is desired that the 144 lags between the play points of the clients and streaming source be 145 small. 147 P2P cache: A P2P cache refers to a network entity that stores 148 (caches) P2P traffic in the network and, either transparently or 149 explicitly, streams content to other peers. 151 Peer: A peer refers to a participant in a P2P streaming system that 152 not only receives streaming content, but also stores and streams 153 streaming content to other participants. 155 Peer list: A list of peers which are in a same swarm maintained by 156 the tracker. A peer can fetch the peer list of a swarm from the 157 tracker or from other peers in order to know which peers have the 158 required streaming content. 160 Peer ID: The identifier of a peer such that other peers, or the 161 tracker, can refer to the peer by using its ID. 163 PPSP: The abbreviation of Peer-to-Peer Streaming Protocols. PPSP 164 refer to the key signaling protocols among various P2P streaming 165 system components, including the tracker and the peer. 167 Tracker: A tracker refers to a directory server that maintains a list 168 of peers participating in a specific audio/video channel or in the 169 distribution of a streaming file. Also, the tracker answers peer list 170 queries received from peers. The tracker is a logical component which 171 can be centralized or distributed. 173 Video-on-demand (VoD): It refers to a scenario where different 174 clients may watch different parts of the same recorded media with 175 downloaded content. 177 Swarm: A swarm refers to a group of peers who exchange data to 178 distribute chunks of the same content (e.g. video/audio program, 179 digital file, etc) at a given time. 181 Swarm ID: The identifier of a swarm containing a group of peers 182 sharing a common streaming content. 184 3. Problem statement 186 The problems caused by proprietary protocols for P2P streaming 187 applications are listed as follows. 189 3.1. Heterogeneous P2P traffic and P2P caches deployment 191 ISPs are faced to different P2P streaming application introducing 192 substantial traffic into their infrastructure, including their 193 backbone and their exchange/interconnection points. P2P caches are 194 used by ISPs in order to locally store content and hence reduce the 195 P2P traffic. P2P caches usually operate at the chunk or file 196 granularity. 198 However, unlike Web traffic that is represented by HTTP packets and 199 therefore allows any caching device to be deployed (as long as it 200 supports HTTP), P2P traffic is originated by multiple P2P 201 applications which require the ISPs to deploy different type of 202 caches for the different types of P2P streams present in the network. 204 This increases both engineering and operational costs dramatically. 206 3.2. Latency efficiency difficulties 208 P2P streaming is often criticized due to its longer delays (e.g., 209 startup delay, seek delay and channel switch delay) compared to 210 client/server streaming. Hybrid CDN/P2P is a good approach in order 211 to address this problem [Hybrid CDN P2P]. 213 In the Hybrid CDN/P2P approach, the CDN takes two roles: media 214 streaming server and P2P tracker. Similarly to what described in 215 section 3.1, proprietary P2P protocols introduce complexity between 216 peers and CDN trackers because the CDN trackers need to identify each 217 different P2P streaming protocol. This increases the deployment cost 218 of CDN. 220 3.3. Extended applicability in mobile and wireless environment 222 Mobility and wireless are becoming increasingly important in today's 223 Internet, where streaming service is a major usage. It's reported 224 that the average volume of video traffic on mobile networks has risen 225 up to 50% in the early of 2012 [ByteMobile]. There are multiple prior 226 studies exploring P2P streaming in mobile and wireless networks 228 [Mobile Streaming1] [Mobile Streaming2]. 230 However it's difficult to apply current P2P streaming protocols (even 231 assuming we can re-use some of the proprietary ones) in mobile and 232 wireless networks. Although smart handsets are more eligible to 233 become peers with much higher bandwidth, CPU frequency, larger 234 storage and memory than before, peer selection will become more 235 challenging due to the increase and complexity of exchange between 236 peers and trackers. Current P2P protocols are not well suited for 237 these new requirements in the context of mobile and wireless 238 networks. 240 Following are some illustrative examples: 241 First, the connections are unstable and expensive in terms of energy 242 consumption and transmission (especially in uplink direction). Peers 243 and trackers may need more information like packet loss rate, peer 244 battery status and processing capability during peer selection. 245 Unfortunately current protocols don't cover this kind of information. 247 Second, current practices often use a "bitmap" message in order to 248 exchange chunk availability. The message is of kilobytes in size and 249 exchanged frequently, for example, several seconds. In a mobile 250 environment with scarce bandwidth, the message size need to be 251 shortened or it may require more efficient methods for expressing and 252 distributing chunk availability information, which is different from 253 current practice. 255 Third, for a resource constraint peer like mobile handsets or set-top 256 boxes (STB), there are severe contentions on limited resource when 257 using proprietary protocols. The peer has to install many different 258 streaming applications for different usages, e.g., some for movies 259 and others for sports and each of these applications will compete for 260 the same set of memories, flashes or hard disks(some may run in the 261 background even they are not invoked by the users). Open protocols creat 262 an opportunity to use one client software accommodating different P2P systems. 263 This may alleviate this problem. 265 4. PPSP: Standard peer to peer streaming protocols 267 PPSP is targeted to standardize signaling protocols for tracker-based 268 architectures to solve the above problems that support either live or 269 VoD streaming. 271 The PPSP design includes a signaling protocol between trackers and 272 peers (the PPSP "tracker protocol") and a signaling protocol among 273 the peers (the PPSP "peer protocol") as shown in Figure 1. The two 274 protocols enable peers to receive streaming data within the time 275 constraints. The tracker protocol handles the initial and periodic 276 exchange of meta-information between trackers and peers, such as 277 peer-list and content information. The peer protocol controls the 278 advertising and exchange of media data between the peers. 280 +------------------------------------------------+ 281 | | 282 | +--------------------------------+ | 283 | | Tracker | | 284 | +--------------------------------+ | 285 | | ^ ^ | 286 |Tracker | | Tracker |Tracker | 287 |Protocol| | Protocol |Protocol | 288 | | | | | 289 | V | | | 290 | +---------+ Peer +---------+ | 291 | | Peer |<----------->| Peer | | 292 | +---------+ Protocol +---------+ | 293 | | ^ | 294 | | |Peer | 295 | | |Protocol | 296 | V | | 297 | +---------------+ | 298 | | Peer | | 299 | +---------------+ | 300 | | 301 | | 302 +------------------------------------------------+ 303 Figure 1 PPSP System Architecture 305 4.1. Tracker protocol candidates discussion and design issues 307 Tracker protocol: The tracker protocol is best modeled as a 308 request/response protocol between peers and trackers, and will carry 309 information needed for the selection of peers suitable for real- 310 time/VoD streaming. 312 One of the main aspects the new protocol has to address is the format 313 of the protocol messages. Two options have been identified: 315 Binary based: Binary based tracker protocols are widely used in 316 practice, e.g., PPLive[PPLive] and PPStream [PPStream]. Binary based 317 tracker protocol is simple with the smallest set of semantic 318 definitions and efficient in peer and tracker resource usage, 319 especially, for mobile and set-top box terminals. 321 Text based: HTTP can be easily thought to be the candidate, being a 322 text based request/response protocol. HTTP messages may be reused for 323 PPSP semantics and if they don't match PPSP requirements, some new 324 messages may be redefined. Another approach consists of using 325 HTTP+XML combination, where HTTP is only used as the underlying 326 transport protocol (in application-level) while tracker information 327 and messages are defined in XML format. 329 PPSP tracker protocol will select the best of the above options 330 according to the requirements from both peer and tracker perspective 331 and also taking into consideration deployment and operation 332 perspectives. 334 4.2. Peer protocol candidates discussion and design issues 336 Peer Protocol: The peer protocol is modeled as a gossip-like protocol 337 with periodic exchanges of neighbor and media chunk availability 338 information. Namely, the peer protocol is a content-centric protocol 339 built around the abstraction of a cloud of participants disseminating 340 the same data in ways and orders that are convenient to the 341 participants [I-D.ietf-ppsp-peer-protocol]. In that respect and in 342 light of the above requirements, typical HTTP is neither suitable nor 343 efficient. 345 We list two peer protocol candidates: 347 Websockets for bidirectional HTTP: WebSockets is basically a 348 bidirectional TCP connection derived from a HTTP connection hence 349 allowing a bidirectional P2P transport over HTTP. On the negative 350 side, TCP is not ideally suited for multi-party transfers of the same 351 content (see Rationale section in I-D.ietf-ppsp-peer-protocol) and 352 therefore it introduces implementation (i.e., code) complexity. 354 UDP based: Unlike TCP or HTTP, UDP is a datagram-based protocol 355 without any sequential data stream abstraction which is, in most the 356 cases, unnecessary for PPSP. Compared to the use of TCP, it reduces 357 the per-connection footprint and complexity of TCP especially in 358 resource constraint mobile cases. 360 The PPSP peer protocol will discuss the protocol design rationales in 361 detail. 363 5. Use cases of PPSP 365 5.1. Worldwide provision of live/VoD streaming 367 The content provider can efficiently increase live streaming coverage 368 by introducing PPSP in between different providers. 370 Figure 2 shows the case of provider A broadcasting a TV program with 371 the help of provider B and C for a wider coverage by introducing PPSP. 372 Without PPSP, when users outside A requests TV program@A, the 373 returned peer-list may include few local peers. This may affect the 374 user experience. With PPSP, B and C can involve in the broadcasting. 375 The providers often deploy in-network peers called super-nodes (SN 376 for short) who have better stability and higher storage and bandwidth 377 for better QoS. With the tracker protocol, the tracker@A can return a 378 peer-list containing, in addition to peers@A addresses, the SNs owned 379 by B and C. Hence User@B and User@C can exchange data (availability) 380 with these local SNs using the peer protocol. 382 Figure 3 shows the case of cooperative VoD provision by introducing 383 PPSP inside CDN overlays and in between different CDNs. It is similar 384 to Figure 2 except that the intermediate SNs are replaced by 3rd 385 party CDN surrogates. The CDN nodes talk with the different streaming 386 systems with the same PPSP protocols. Note that for compatibility 387 reason both HTTP streaming and P2P streaming can be supported by CDN. 389 The interaction between the CDN nodes can be executed by either 390 existing (maybe proprietary) protocols or the PPSP peer protocol. The 391 peer protocol is useful for building new CDN systems supporting 392 streaming in a low cost. 394 +-------------------------------------------------------------------+ 395 | | 396 | +------------------+ | 397 | +------------>| A's Tracker |<----------+ | 398 | | +------------------+ | | 399 | Tracker| ^ ^ | | 400 | Protocol| Tracker| |Tracker |Tracker | 401 | | Protocol| |Protocol |Protocol | 402 | | | | | | 403 | | | | | | 404 | v v v v | 405 | +------+ Peer +------+ +------+ +------+ | 406 | | B's |<------->| B's | | C's | | C's | | 407 | | SN1 |Protocol | SN2 | | SN1 | | SN2 | | 408 | +------+ +------+ +------+ +------+ | 409 | ^ ^ ^ ^ | 410 | | | | | | 411 | | | Peer Protocol Peer Protocol| | | 412 | Peer | +-------------+ +--------------+ |Peer | 413 | Protocol| | | |protocol| 414 | | | | | | 415 | | | | | | 416 | | | | | | 417 | v v v v | 418 | +------+ Peer +------+ +---------+ Peer +---------+ | 419 | | A's |<------> | B's | |A's |<------> |C's | | 420 | | User1|Protocol | User2| | User1 |Protocol | User2 | | 421 | +------+ +------+ +---------+ +---------+ | 422 | | 423 +-------------------------------------------------------------------+ 424 Figure 2 Cooperative Vendors Interaction 426 +-------------------------------------------------------------------+ 427 | | 428 | +-------------+ +--------------+ | 429 | +----->| A's Tracker | | B's Tracker |<---+ | 430 | | +-------------+ +--------------+ | | 431 | Tracker| ^ ^ ^ ^ | | 432 | Protocol| Tracker| |Tracker | |Tracker |Tracker | 433 | | Protocol| |Protocol| |Protocol |Protocol| 434 | | | | | | | | 435 | | | | | | | | 436 | v v | | v v | 437 | +------+ Peer +------+| | +------+Internal+------+ | 438 | | CDN |<------>| CDN || | | CDN |<-----> | CDN | | 439 | | Node1|Protocol| Node2|| | | Node3|Protocol| Node4| | 440 | +------+ +------+| | +------+ +------+ | 441 | ^ ^ | | ^ ^ | 442 | | | | | | | | 443 | | | Peer Protocol | | HTTP | | | 444 | Peer | +-------------+ | | +------+ | Peer | 445 | Procotol| | | | | Protocol |protocol| 446 | | | +-+ | | | | 447 | | | | | | | | 448 | | | | | | | | 449 | v v v v v v | 450 | +------+ Peer +------+ +---------+ Peer +---------+ | 451 | | A's |<------> | A's | |B's |<------> |B's | | 452 | | User1|Protocol | User2| | User3 |Protocol | User4 | | 453 | +------+ +------+ +---------+ +---------+ | 454 | | 455 +-------------------------------------------------------------------+ 456 Figure 3 CDN Supporting P2P Streaming 458 5.2. Cross-screen streaming 460 In this scenario PC, STB/TV and mobile terminals from both fixed 461 network and mobile/wireless network share the streaming content. With 462 PPSP, peers can identify the types of access networks, average load, 463 peer abilities and get to know what content other peers have even in 464 different networks (potentially with the conversion of the content 465 availability expression in different networks) as shown in Figure 4. 467 Such information will play an important role on selecting suitable 468 peers, e.g., a PC or STB is more likely to provide stable content and 469 a mobile peer within a high-load cell is unlikely to be selected, 470 which may otherwise lead to higher load on the base station. 472 +-------------------------------------------------------------------+ 473 | | 474 | Tracker Protocol +---------+ Tracker Protocol | 475 | +-------------> | Tracker |<------------------+ | 476 | | +---------+ | | 477 | | ^ | | 478 | | | | | 479 | | | | | 480 | V | V | 481 | +------+ | +------------+ | 482 | | STB | Tracker Protocol |Mobile Phone| | 483 | +------+ | +------------+ | 484 | ^ | ^ | 485 | | | | | 486 | | | | | 487 | | V | | 488 | |Peer Protocol +---------+ Peer Protocol | | 489 | +-------------> | PC |<------------------+ | 490 | +---------+ | 491 | | 492 +-------------------------------------------------------------------+ 493 Figure 4 Heterogeneous P2P Streaming with PPSP 495 5.3. Cache service supporting P2P streaming 497 In Figure 5, when peers request the P2P streaming data, the cache 498 nodes intercept the requests and ask for the frequently visited 499 content (or part of) on behalf of the peers. To do this, it asks the 500 tracker for the peer-list and the tracker replies with external peers 501 in the peer-list. After the cache nodes exchange data with these 502 peers, it can also act as a peer and report what it caches to the 503 tracker and serve requesting peers inside afterward. This operation 504 greatly decreases the inter-network traffic and increases user 505 experience. 507 The cache nodes do not need to update their library when new 508 applications supporting PPSP are introduced, which reduces the cost. 510 +----------------------------------------------------------------+ 511 | | 512 | Tracker Protocol +---------+ | 513 | +----------------> | Tracker | | 514 | | +---------+ | 515 | | ^ | 516 | | | | 517 | | | Tracker Protocol | 518 | | | | 519 | | | | 520 | | +---------|-------------------------------------| 521 | | | V | 522 | | | +---------+ | 523 | | +----------|---> | Cache |<-------------------+ | 524 | | | | +---------+ Tracker/Peer| | 525 | | | Peer | Protocol | | 526 | | | Protocol | | | 527 | | | | | | 528 | | | | | | 529 | V V | V | 530 | +-----------+ | ISP Domain +------------+ | 531 | | External | | | Inside | | 532 | | Peer | | | Peer | | 533 | +-----------+ | +------------+ | 534 +----------------------------------------------------------------+ 536 Figure 5 Cache Service Supporting Streaming with PPSP 538 5.4. Proxy service supporting P2P streaming 540 5.4.1. Home Networking Scenario 542 For applications where the peer is not co-located with the media 543 player in the same device (e.g. the peer is located in a home media 544 gateway), we can use a PPSP proxy, as shown in figure 6. 546 As shown in figure 6, the PPSP proxy terminates both the tracker and 547 peer protocol allowing the legacy presentation devices to access P2P 548 streaming content. In figure 6 the DLNA protocol [DLNA] is used in 549 order to communicate with the presentation devices thanks to its wide 550 deployment. Obviously, other protocols can also be used. 552 +----------------------------------------------------------------+ 553 | | 554 | Tracker Protocol +---------+ | 555 | +----------------> | Tracker | | 556 | | +---------+ | 557 | | ^ | 558 | | | | 559 | | | Tracker Protocol | 560 | | | | 561 | | +---------|-------------------------------------| 562 | | | V | 563 | | | +---------+ | 564 | | +----------|---> | PPSP |<-------------------+ | 565 | | | | | Proxy | DLNA | | 566 | | | Peer | +---------+ Protocol | | 567 | | | Protocol | | | 568 | | | | | | 569 | V V | V | 570 | +-----------+ | Home Domain +------------+ | 571 | | External | | | DLNA Pres.| | 572 | | Peer | | | Devices | | 573 | +-----------+ | +------------+ | 574 +----------------------------------------------------------------+ 576 Figure 6 Proxy service Supporting P2P Streaming 578 5.4.2. Browser-based HTTP Streaming 580 P2P Plug-ins can be used in browser-based environment in order to 581 stream content. With P2P plug-ins, HTTP streaming can be turned into 582 a de facto P2P streaming. From the browser (and hence the user) 583 perspective, it's just HTTP based streaming but the PPSP capable 584 plug-in can actually accelerate the process by leveraging streams 585 from multiple sources/peers [P2PYoutube]. In this case the plug-ins 586 behave just like the proxy. 588 6. Requirements of PPSP 590 This section enumerates the requirements that should be considered 591 when designing PPSP. 593 6.1. Basic Requirements 595 PPSP.REQ-1: The tracker and the peer protocol SHOULD allow peers to 596 receive streaming content within the required time constraints. 598 PPSP.REQ-2: Each peer MUST have a unique ID (i.e. peer ID) in a swarm. 600 It's a basic requirement for a peer to be uniquely identified in a 601 swarm that other peers or tracker can refer to the peer by ID. 603 PPSP.REQ-3: The streaming content MUST be uniquely identified by a 604 swarm ID. 606 A swarm refers to a group of peers sharing the same streaming content. 607 A swarm ID uniquely identifies a swarm. The swarm ID can be used in 608 two cases: 1) a peer requests the tracker for the peer list indexed 609 by a swarm ID; 2) a peer tells the tracker about the swarms it 610 belongs to. 612 PPSP.REQ-4: The streaming content MUST allow to be partitioned into 613 chunks. 615 A key characteristic of P2P streaming system is allowing the data 616 fetching from different peers concurrently. Therefore, the whole 617 streaming content must allow to be partitioned into small pieces or 618 chunks for transmission between peers. 620 PPSP.REQ-5: Each chunk MUST have a unique ID (i.e. chunk ID) in the 621 swarm. 623 Each chunk must have a unique ID in the swarm so that the peer can 624 understand which chunks are stored in which peers and which chunks 625 are requested by other peers. An example for generating the chunk ID 626 is the bitmap approach [I-D.ietf-ppsp-survey]. 628 PPSP.REQ-6: The tracker protocol and peer protocol are recommended to 629 be carried over TCP or UDP. 631 PPSP.REQ-7: The tracker and peer protocol together MUST facilitate 632 acceptable QoS (e.g. low startup delay, low channel/content switching 633 time and minimal end-to-end delay) for both live and VoD streaming 634 even for very popular content. The tracker and peer protocol do not 635 include the algorithm required for scalable streaming. However, the 636 tracker and peer protocol SHALL NOT restrict or place limits on any 637 such algorithm. 639 There are basic QoS requirements for streaming systems. Setup time to 640 receive a new streaming channel or to switch between channels should 641 be reasonably small. End to end delay, which consists of the time 642 between content generation (e.g., a camera) and content consumption 643 (e.g., a monitor), will become critical in case of live streaming 644 especially in provisioning of sport events where end to end delay of 645 1 minute and more are not acceptable. 647 For instance, the tracker and peer protocol can carry QoS related 648 parameters (e.g. video quality and delay requirements) together with 649 the priorities of these parameters in addition to the measured QoS 650 situation (e.g., performance, available uplink bandwidth) of content 651 providing peers. 653 There are also some other possible mechanisms like addition of super 654 peers, in-network storage, request of alternative peer addresses, and 655 the usage of QoS information for advanced peer selection mechanisms. 657 6.2. PPSP Tracker Protocol Requirements 659 The tracker protocol defines how the peers report and request 660 information to/from the tracker and how the tracker replies to the 661 requests. The tracker discovery and the possible communication 662 between trackers are out of the scope of tracker protocol. 664 PPSP.TP.REQ-1: The tracker MUST implement the tracker protocol for 665 receiving queries, sending the corresponding replies and periodical 666 send peer status reports/updates. 668 PPSP.TP.REQ-2: The peer MUST implement the tracker protocol for 669 sending queries and periodical peer status reports/updates to the 670 tracker and receiving the corresponding replies. 672 PPSP.TP.REQ-3: The tracker request message MUST allow the requesting 673 peer to solicit the peer list from the tracker with respect to a 674 specific swarm ID. 676 The tracker request message may also include the requesting peer's 677 preference parameter (e.g. preferred number of peers in the peer list) 678 or preferred downloading bandwidth. The tracker will then be able to 679 select an appropriate set of peers for the requesting peer according 680 to the preference. 682 PPSP.TP.REQ-4: The tracker reply message MUST allow the tracker to 683 offer the peer list to the requesting peer with respect of a specific 684 swarm ID. 686 PPSP.TP.REQ-5: The tracker SHOULD support generating the peer list 687 with the help of traffic optimization services, e.g. ALTO [I-D.ietf- 688 alto-protocol]. 690 PPSP.TP.REQ-6: The peer status report/update MUST have the ability to 691 inform the tracker about the peer's activity in the swarm. 693 PPSP.TP.REQ-7: The chunk availability information of the peer SHOULD 694 be reported to tracker when tracker needs such information to steer 695 peer selection. The chunk information MUST at least contain the 696 chunk ID. 698 PPSP.TP.REQ-8: The chunk availability information between peer and 699 tracker MUST be expressed as compact as possible. 701 The peers may report chunk availability digest information (i.e., 702 compact expression of chunk availability) to the tracker when 703 possible in order to decrease the bandwidth consumption in mobile 704 networks. For example, if a peer has a bitmap like 111111...1(one 705 hundred continuous 1)xxx..., the one hundred continuous "1" can be 706 expressed by one byte with seven bits representing the number of "1", 707 i.e., "one hundred" and one bit representing the continuous sequence 708 is "1" or "0". In this example, 100-8=92 bits are saved. Considering 709 the frequency of exchange of chunk availability and the fact that 710 many bitmaps have a quite long length of continuous "1" or "0", such 711 compression is quite useful. 713 PPSP.TP.REQ-9: The status of the peer SHOULD be reported to the 714 tracker when tracker needs such information in order to steer peer 715 selection. 717 For example, peer status can be online time, physical link status 718 including DSL/WiFi/etc., battery status, processing capability and 719 other capabilities of the peer. Therefore, the tracker is able to 720 select better candidate peers for streaming. 722 6.3. PPSP Peer Protocol Requirements 724 The peer protocol defines how the peers advertise streaming content 725 availability and exchange status with each other. The peer protocol 726 also defines the requests and responses of the chunks among the 727 peers. 729 PPSP.PP.REQ-1: The streaming content availability request message 730 MUST allow the peer to solicit the chunk information from other peers 731 in the peer list. The chunk information MUST at least contain the 732 chunk ID. This chunk availability information MUST NOT be passed on 733 to other peer, unless validated (e.g. prevent hearsay and DoS). 735 PPSP.PP.REQ-2: The streaming content availability reply message MUST 736 allow the peer to offer the information of the chunks in its content 737 buffer. The chunk information MUST at least contain the chunk ID. 739 PPSP.PP.REQ-3: The streaming content availability request message 740 SHOULD allow the peer to solicit an additional list of peers to that 741 received from the tracker - with the same swarm ID. The reply 742 message MUST contain swarm-membership information of the peers that 743 have explicitly indicated they are part of the swarm, verifiable by 744 the receiver. This additional list of peers MUST only contain peers 745 which have been checked to be valid and online recently (e.g. prevent 746 hearsay and DoS). 748 It is possible that a peer may need additional peers for certain 749 streaming content. Therefore, it is allowed that the peer 750 communicates with other peers in the current peer list to obtain an 751 additional list of peers in the same swarm. 753 PPSP.PP.REQ-4: Streaming content availability update message among 754 the peers MUST be supported by the peer protocol. The peer protocol 755 MUST implement either pull-based, push-based or both. 757 Due to the dynamic change of the buffered streaming content in each 758 peer and the frequent join/leave of peers in the swarm, the streaming 759 content availability among a peer's neighbors (i.e. the peers known 760 to a peer by getting the peer list from either tracker or peers) 761 always changes and thus requires being updated on time. This update 762 should be done at least on demand. For example, when a peer requires 763 finding more peers with certain chunks, it sends a message to some 764 other peers in the swarm for streaming content availability update. 765 Alternatively, each peer in the swarm can advertise its streaming 766 content availability to some other peers periodically. However, the 767 detailed mechanisms for this update such as how far to spread the 768 update message, how often to send this update message, etc. should 769 leave to the algorithms, rather than protocol concerns. 771 PPSP.PP.REQ-5: The chunk availability information between peers MUST 772 be expressed as compactly as possible. 774 In PP.REQ-1/2/4, the peers may exchange chunk availability digest 775 information with other peers, when possible, in order to decrease the 776 messages bandwidth consumption. 778 PPSP.PP.REQ-6: The peer status report/update SHOULD be advertised 779 among the peers in order to reflect the status of the peer. Peer 780 status information should be advertised among the peers via the 781 peer status report/update message. For example, peer status can be 782 online time, physical link status including DSL/WiFi/etc, battery 783 status, processing capability, and other capabilities of the peer. 784 With such information, a peer can select more appropriate peers for 785 streaming. 787 PPSP.PP.REQ-7: The peers MUST implement the peer protocol for chunk 788 data (not availability information) requests and responses among the 789 peers before the streaming content is transmitted. 791 7. Security Considerations 793 This document discusses the problem statement and requirements around 794 P2P streaming protocols without specifying the protocols. However we 795 believe it is important for the reader to understand areas of 796 security introduced by the P2P nature of the proposed solution. The 797 main issue is the usage of un-trusted entities (peers) for service 798 provisioning. For example, malicious peers may: 800 - Originate denial of service (DOS) attacks to the trackers by 801 sending large amount of requests with the tracker protocol; 802 - Originate fake information on behalf of other peers; 803 - Originate fake information about chunk availability; 805 For example, malicious peers/trackers may: 806 - Originate reply instead of the regular tracker (man in the middle 807 attack). 809 We list some important security requirements for PPSP protocols as 810 below: 812 PPSP.SEC.REQ-1: PPSP MUST support closed swarms, where the peers are 813 authenticated. 815 This ensures that only the authenticated users can access the 816 original media in the P2P streaming system. This can be achieved by 817 security mechanisms such as user authentication and/or key management 818 scheme. 820 PPSP.SEC.REQ-2: Confidentiality of the streaming content in PPSP 821 SHOULD be supported and the corresponding key management scheme 822 SHOULD scale well in P2P streaming systems. 824 PPSP.SEC.REQ-3: PPSP MUST provide an option in order to encrypt the 825 data exchange among the PPSP entities. 827 PPSP.SEC.REQ-4: PPSP MUST have mechanisms in order to limit potential 828 damage caused by malfunctioning and badly behaving peers in the P2P 829 streaming system. 831 Such an attack will degrade the quality of the rendered media at the 832 receiver. For example, in a P2P live streaming system a polluter can 833 introduce corrupted chunks. Each receiver integrates into its 834 playback stream the polluted chunks it receives from its neighbors. 835 Since the peers forwards chunks to other peers, the polluted content 836 can potentially spread through the P2P streaming network. 838 PPSP.SEC.REQ-5: PPSP SHOULD support identifying badly behaving peers, 839 and exclude or reject them from the P2P streaming system. 841 PPSP.SEC.REQ-6: PPSP MUST prevent peers from DoS attacks which will 842 exhaust the available resources of the P2P streaming system. 844 Given the prevalence of DoS attacks in the Internet, it is important 845 to realize that a similar threat could exist in a large-scale 846 streaming system where attackers are capable of consuming a lot of 847 resources with just a small amount of effort. 849 PPSP.SEC.REQ-7: PPSP SHOULD be robust, i.e., when centralized tracker 850 fails, the P2P streaming system SHOULD still work by supporting 851 distributed trackers. 853 PPSP.SEC.REQ-8: Existing P2P security mechanisms SHOULD be re-used as 854 much as possible in PPSP, to avoid developing new security mechanisms. 856 PPSP.SEC.REQ-9: Integrity of the streaming content in PPSP MUST be 857 supported to provide a peer with the possibility to identify 858 unauthentic media content (undesirable modified by other entities 859 rather than its genuine source). The corresponding checksum 860 distribution and verification scheme SHOULD scale well in P2P 861 streaming system and be robust against distrustful trackers/peers. 863 The PPSP protocol specifications will document the expected threats 864 (and how they will be mitigated by each protocol) and also 865 considerations on threats and mitigations when combining both 866 protocols in an application. This will include privacy of the users 867 and protection of the content distribution. Protection of the content 868 by Digital Rights Management (DRM) is outside the scope of the PPSP. 870 8. IANA Considerations 872 This document has no actions for IANA. 874 9. Acknowledgments 876 Thank you to J.Seng, G. Camarillo, R. Yang, C. Schmidt, R. Cruz and S. 877 Previdi for contribution to many sections of this draft. Thank you to 878 C. Williams, V. Pasual and L. Xiao for contributions to PPSP 879 requirements section. 880 We would like to acknowledge the following people who provided 881 review, feedback and suggestions to this document: M. Stiemerling, D. 882 Bryan, E. Marocco, V. Gurbani, R. Even, H. Zhang, D. Zhang, J. Lei, 883 Y.Gu, H.Song, X.Jiang, J.Seedorf, D.Saumitra, A.Rahman, L.Deng, 884 J.Pouwelse, A.Bakker and W.Eddy. 886 This document was prepared using 2-Word-v2.0.template.dot. 888 10. Informative References 890 [Cisco] Cisco Visual Networking Index: Forecast and Methodology, 891 2009-2014, 892 http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns7 893 05/ns827/white_paper_c11- 894 481360_ns827_Networking_Solutions_White_Paper.html 896 [VoD] Y. Huang et al, Challenges, "Design and Analysis of a Large- 897 scale P2P-VoD System", Sigcomm08. 899 [ByteMobile] http://www.bytemobile.com/news- 900 events/2012/archive_230212.html 902 [Mobile Streaming1] Streaming to Mobile Users in a Peer-to-Peer 903 Network, J. Noh et al, MOBIMEDIA '09. 905 [Mobile Streaming2] J.Peltotaloet al.,"A real-time Peer-to-Peer 906 streaming system for mobile networking environment", in Proceedings 907 of the INFOCOM and Workshop on Mobile Video Delivery (MoVID '09). 909 [I-D.ietf-alto-protocol]R. Alimi et al, "ALTO Protocol", draft-ietf- 910 alto-protocol-10 (work in progress), October 2011. 912 [Hybrid CDN P2P]D. Xu et al, "Analysis of a CDN-P2P hybrid 913 architecture for cost-effective streaming media distribution," 914 Springer Multimedia Systems, vol.11, no.4, pp.383-399, 2006. 916 [I-D.ietf-ppsp-survey] Y. Gu et al, "Survey of P2P Streaming 917 Applications", draft-ietf-ppsp-survey-02 (work in progress), July 918 2011. 920 [PPTV] http://www.pptv.com 922 [PPStream] http://www.ppstream.com 924 [I-D.ietf-ppsp-peer-protocol] A. Bakker et al, Peer-to-Peer Streaming 925 Peer Protocol (PPSPP),draft-ietf-ppsp-peer-protocol-02, (work in 926 progress), June 2012. 928 [DLNA] http://www.dlna.org 930 [P2PYoutube] https://addons.opera.com/en/extensions/details/p2p- 931 youtube/ 933 Authors' Addresses 935 Yunfei Zhang 936 China Mobile Communication Corporation 937 zhangyunfei@chinamobile.com 939 NingZong 940 Huawei Technologies Co., Ltd. 941 zongning@huawei.com