idnits 2.17.1 draft-ietf-ppsp-problem-statement-13.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 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 27 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 418 has weird spacing: '...is only provi...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ByteMobile' is mentioned on line 242, but not defined == Unused Reference: 'PPTV' is defined on line 1002, but no explicit reference was found in the text == Unused Reference: 'PPStream' is defined on line 1004, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-13 Summary: 1 error (**), 0 flaws (~~), 8 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 Huawei 6 Intended status: Informational February 20,2013 7 Expires: August 2013 9 Problem Statement and Requirements of Peer-to-Peer Streaming 10 Protocol (PPSP) 11 draft-ietf-ppsp-problem-statement-13.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 18 the development of Peer to Peer Streaming Protocol(PPSP) including 19 the Tracker and Peer protocol, and discusses the scope, requirements 20 and use 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 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference 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 August 20, 2013. 45 Copyright Notice 47 Copyright (c) 2013 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 Provisions 51 Relating to IETF Documents (http://trustee.ietf.org/license-info) 52 in effect on the date of publication of this document. Please 53 review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License 56 text as described in Section 4.e of the Trust Legal Provisions 57 and are provided without warranty as described in the Simplified 58 BSD License. 60 Table of Contents 62 1. Introduction ................................................ 4 63 1.1. Background ............................................. 4 64 1.2. Requirements Language .................................. 4 65 2. Terminology and concepts .................................... 5 66 3. Problem statement ........................................... 7 67 3.1. Heterogeneous P2P traffic and P2P cache deployment....... 7 68 3.2. QoS issue and CDN deployment ............................ 7 69 3.3. Extended applicability in mobile and wireless environment 7 70 4. Tasks of PPSP: Standard peer to peer streaming protocols...... 9 71 4.1. Tasks and design issues of Tracker protocol ............ 10 72 4.2. Tasks and design issues of Peer protocol ............... 11 73 5. Use cases of PPSP .......................................... 12 74 5.1. Worldwide provision of live/VoD streaming .............. 12 75 5.2. Enabling CDN for P2P VoD streaming ..................... 12 76 5.3. Cross-screen streaming ................................. 14 77 5.4. Cache service supporting P2P streaming ................. 15 78 5.5. Proxy service supporting P2P streaming ................. 16 79 5.5.1. Home networking scenario .......................... 16 80 5.5.2. Browser-based HTTP streaming ...................... 17 81 6. Requirements of PPSP ........................................ 17 82 6.1. Basic Requirements ..................................... 17 83 6.2. Operation & Management Requirements .................... 18 84 6.2.1. Operation Considerations .......................... 18 85 6.2.2. Management Considerations ......................... 19 86 6.3. PPSP Tracker Protocol Requirements ..................... 20 87 6.4. PPSP Peer Protocol Requirements ........................ 21 88 7. Security Considerations ..................................... 22 89 8. IANA Considerations ........................................ 23 90 9. Acknowledgments ............................................ 24 91 10. References ................................................ 24 92 10.1. Normative References .................................. 24 93 10.2. Informative References ................................ 25 95 1. Introduction 97 1.1. Background 99 Streaming traffic is among the largest and fastest growing traffic 100 on the Internet [Cisco], where peer-to-peer (P2P) streaming 101 contributes substantially. With the advantage of high scalability 102 and fault tolerance against single point of failure, P2P streaming 103 applications are able to distribute large-scale, live and video on 104 demand (VoD) streaming programs to a large audience with only a 105 handful of servers. What's more, along with the players like CDN 106 providers joining in the effort of using P2P technologies in 107 distributing their serving streaming content, there are more and 108 more various players in P2P streaming ecosystem. 110 Given the increasing integration of P2P streaming into the global 111 content delivery infrastructure, the lack of an open, standard P2P 112 streaming signaling protocol suite becomes a major missing component. 113 Almost all of existing systems use their proprietary protocols. 114 Multiple, similar but proprietary protocols result in repetitious 115 development efforts for new systems, and the lock-in effects lead to 116 substantial difficulties in their integration with other players 117 like CDN. For example, in the enhancement of existing caches and CDN 118 systems to support P2P streaming, proprietary protocols may increase 119 the complexity of the interaction with different P2P streaming 120 applications. 122 In this document we propose the development of an open P2P Streaming 123 Protocol, which is abbreviated as PPSP, to standardize signaling 124 operations in P2P streaming systems to solve the above problems. 126 1.2. Requirements Language 128 The key words "MUST" and "MUST NOT" in this document are to be 129 interpreted as described in RFC 2119 [RFC2119] and indicate 130 requirement levels for compliant implementations. 132 2. Terminology and concepts 134 CHUNK: A CHUNK is a basic unit of data organized in P2P streaming 135 for storage, scheduling, advertisement and exchange among peers 136 [VoD]. A CHUNK size varies from several KBs to several MBs in 137 different systems. In case of MBs size CHUNK scenario, a sub-CHUNK 138 structure named piece is often defined to fit in a single 139 transmitted packet. A streaming system may use different 140 granularities for different usage, e.g., using CHUNKs during data 141 exchange, and using a larger unit such as a set of CHUNKs during 142 advertisement. 144 CHUNK ID: The identifier of a CHUNK in a content stream. 146 CLIENT: A CLIENT refers to a participant in a P2P streaming system 147 that only receives streaming content. In some cases, a node not 148 having enough computing and storage capabilities will act as a 149 CLIENT. Such node can be viewed as a specific type of PEER. 151 CONTENT DISTRIBUTION NETWORK (CDN): A CDN is a collection of nodes 152 that are deployed, in general, at the network edge like Points of 153 Presence (POP) or Data Centers (DC) and that store content provided 154 by the original content servers. Typically, CDN nodes serve content 155 to the users located nearby topologically. 157 LIVE STREAMING: It refers to a scenario where all the audiences 158 receive streaming content for the same ongoing event. It is desired 159 that the lags between the play points of the audiences and streaming 160 source be small. 162 P2P CACHE: A P2P CACHE refers to a network entity that caches P2P 163 traffic in the network and, either transparently or explicitly, 164 streams content to other PEERs. 166 PEER: A PEER refers to a participant in a P2P streaming system that 167 not only receives streaming content, but also caches and streams 168 streaming content to other participants. 170 PEER LIST: A list of PEERs which are in a same SWARM maintained by 171 the TRACKER. A PEER can fetch the PEER LIST of a SWARM from the 172 TRACKER or from other PEERs in order to know which PEERs have the 173 required streaming content. 175 PEER ID: The identifier of a PEER such that other PEERs, or the 176 TRACKER, can refer to the PEER by using its ID. 178 PPSP: The abbreviation of Peer-to-Peer Streaming Protocols. PPSP 179 refer to the primary signaling protocols among various P2P streaming 180 system components, including the TRACKER and the PEER. 182 TRACKER: A TRACKER refers to a directory service that maintains a 183 list of PEERs participating in a specific audio/video channel or in 184 the distribution of a streaming file. Also, the TRACKER answers PEER 185 LIST queries received from PEERs. The TRACKER is a logical component 186 which can be centralized or distributed. 188 VIDEO-ON-DEMAND (VoD): It refers to a scenario where different 189 audiences may watch different parts of the same recorded streaming 190 with downloaded content. 192 SWARM: A SWARM refers to a group of PEERs who exchange data to 193 distribute CHUNKs of the same content (e.g. video/audio program, 194 digital file, etc) at a given time. 196 SWARM ID: The identifier of a SWARM containing a group of PEERs 197 sharing a common streaming content. 199 SUPER-NODE: A SUPER-NODE is a special kind of PEER deployed by ISPs. 200 This kind of PEER is more stable with higher computing, storage and 201 bandwidth capabilities than normal PEERs. 203 3. Problem statement 205 The problems caused by proprietary protocols for P2P streaming 206 applications are listed as follows. 208 3.1. Heterogeneous P2P traffic and P2P cache deployment 210 ISPs are faced with different P2P streaming application introducing 211 substantial traffic into their infrastructure, including their 212 backbone and their exchange/interconnection points. P2P caches are 213 used by ISPs in order to locally store content and hence reduce the 214 P2P traffic. P2P caches usually operate at the chunk or file 215 granularity. 217 However, unlike web traffic that is represented by HTTP requests and 218 responses and therefore allows any caching device to be served (as 219 long as it supports HTTP), P2P traffic is originated by multiple P2P 220 applications which require the ISPs to deploy different type of 221 caches for the different types of P2P streams. 223 This increases both engineering and operational costs dramatically. 225 3.2. QoS issue and CDN deployment 227 P2P streaming is often criticized due to its worse QoS performance 228 compared to client/server streaming (e.g., longer startup delay, 229 longer seek delay and channel switch delay). Hybrid CDN/P2P is a 230 good approach in order to address this problem [Hybrid CDN P2P]. 232 In order to form the hybrid P2P/CDN architecture, the CDN must be 233 aware of the specific P2P streaming protocol in the collaboration. 234 Similarly to what is described in section 3.1, proprietary P2P 235 protocols introduce complexity and deployment cost of CDN. 237 3.3. Extended applicability in mobile and wireless environment 239 Mobility and wireless are becoming increasingly important in today's 240 Internet, where streaming service is a major usage. It's reported 241 that the average volume of video traffic on mobile networks has 242 risen up to 50% in the early of 2012 [ByteMobile]. There are 243 multiple prior studies exploring P2P streaming in mobile and 244 wireless networks [Mobile Streaming1] [Mobile Streaming2]. 246 However it's difficult to directly apply current P2P streaming 247 protocols (even assuming we can re-use some of the proprietary ones) 248 in mobile and wireless networks. 250 Following are some illustrative problems: 251 First, P2P streaming assumes a stable Internet connection in 252 downlink and uplink direction, with decent capacity and peers that 253 can run for hours. This isn't the typical setting for mobile 254 terminals. Usually the connections are unstable and expensive in 255 terms of energy consumption and transmission (especially in uplink 256 direction). To enable mobile/wireless P2P streaming feasible, 257 trackers may need more information on peers like packet loss rate, 258 peer battery status and processing capability during peer selection 259 compared to fixed peers. Unfortunately current protocols don't 260 convey this kind of information. 262 Second, current practices often use a "bitmap" message in order to 263 exchange chunk availability. The message is of kilobytes in size and 264 exchanged frequently, e.g., an interval of several seconds or less. 265 In a mobile environment with scarce bandwidth, the message size may 266 need to be shortened or it may require more efficient methods for 267 expressing and distributing chunk availability information, which is 268 different from wire-line P2P streaming. 270 Third, for a resource constraint peer like mobile handsets or set- 271 top boxes (STB), there are severe contentions on limited resource 272 when using proprietary protocols. The terminal has to install 273 different streaming client software for different usages, e.g., some 274 for movies and others for sports. Each of these applications will 275 compete for the same set of resources even when it is sometimes 276 running in background mode. PPSP can alleviate this problem with the 277 basic idea that the "one common client software with PPSP and 278 different scheduling plug-ins" is better than "different client 279 software running at the same time" in memory and disk consumption. 281 4. Tasks of PPSP: Standard peer to peer streaming protocols 283 PPSP is targeted to standardize signaling protocols to solve the 284 above problems that support either live or VoD streaming. 285 PPSP supports both centralized tracker and distributed trackers. In 286 distributed trackers, the tracker functionality is distributed in 287 decentralized peers. In the following part of this section, the 288 tracker is a logic conception, which can be implemented in a 289 dedicated tracker server or in peers. 291 The PPSP design includes a signaling protocol between trackers and 292 peers (the PPSP "Tracker protocol") and a signaling protocol among 293 the peers (the PPSP "Peer protocol") as shown in Figure 1. The two 294 protocols enable peers to receive streaming content within the time 295 constraints. 297 PPSP design in general needs to solve the following challenges, 298 e.g.,: 300 1) When joining a swarm, how does a peer know which peers it should 301 contact for content? 303 2) After knowing a set of peers, how does a peer contact with these 304 peers? in which manner? 306 3) How to choose peers with better service capabilities, and how to 307 collect such information from peers? 309 4) How to improve the efficiency of the communication, e.g. compact 310 on-the-wire message format and suitable underlying transport 311 mechanism (UDP or TCP)? 313 5) How to improve the robustness of the system using PPSP, e.g. when 314 the tracker fails? How to make the tracker protocol and the peer 315 protocol loose coupled? 316 +------------------------------------------------+ 317 | | 318 | +--------------------------------+ | 319 | | Tracker | | 320 | +--------------------------------+ | 321 | | ^ ^ | 322 |Tracker | | Tracker |Tracker | 323 |Protocol| | Protocol |Protocol | 324 | | | | | 325 | V | | | 326 | +---------+ Peer +---------+ | 327 | | Peer |<----------->| Peer | | 328 | +---------+ Protocol +---------+ | 329 | | ^ | 330 | | |Peer | 331 | | |Protocol | 332 | V | | 333 | +---------------+ | 334 | | Peer | | 335 | +---------------+ | 336 | | 337 | | 338 +------------------------------------------------+ 339 Figure 1 PPSP System Architecture 341 4.1. Tasks and design issues of Tracker protocol 343 The tracker protocol handles the initial and periodic exchange of 344 meta-information between trackers and peers, such as peer list and 345 content information. 347 Therefore tracker protocol is best modeled as a request/response 348 protocol between peers and trackers, and will carry information 349 needed for the selection of peers suitable for real-time/VoD 350 streaming. 352 Special tasks for the design of the tracker protocol are listed as 353 follows. This is a high-level task-list. The detailed requirements 354 on the design of the tracker protocol are explicated in section 6. 356 1) How should a peer be globally identified? This is related to the 357 peer ID definition, but irrelevant to how the peer ID is generated. 359 2) How to identify different peers, e.g. peers with public or 360 private IP address, peers behind or not behind NAT, peers with IPV4 361 or IPV6 addresses, peers with different property? 362 3) The tracker protocol must be light-weight, since a tracker may 363 need to server large amount of peers. This is related to the 364 encoding issue(e.g., Binary based or Text based) and keep-alive 365 mechanism. 367 4) How can the tracker be able to report optimized peer list to 368 serve a particular content? This is related to status statistic, 369 with which the tracker can be aware of peer status and content 370 status. 372 PPSP tracker protocol will consider all these issues in the design 373 according to the requirements from both peer and tracker perspective 374 and also taking into consideration deployment and operation 375 perspectives. 377 4.2. Tasks and design issues of Peer protocol 379 The peer protocol controls the advertising and exchange of content 380 between the peers. 382 Therefore peer protocol is modeled as a gossip-like protocol with 383 periodic exchanges of neighbor and chunk availability information. 385 Special tasks for the design of the peer protocol are listed as 386 follows. This is a high-level task-list. The detailed requirements 387 on the design of the peer protocol are explicated in section 6. 389 1) How does the certain content be globally identified and verified? 390 Since the content can be retrieved from everywhere, how to ensure 391 the exchanged content between the peers is authentic? 393 2) How to identify the chunk availability in the certain content? 394 This is related to the chunk addressing and chunk state maintenance. 395 Considering the large amount of chunks in the certain content, 396 light-weight expression is necessary. 398 3) How to ensure the peer protocol efficiency? As we mentioned in 399 section 3, the chunk availability information exchange is quite 400 frequent. How to balance the information exchange size and amount is 401 a big challenge. What kind of encoding and underlying transport 402 mechanism (UDP or TCP) is used in the messages? 404 PPSP peer protocol will consider all the above issues in the design 405 according to the requirements from the peer perspective. 407 5. Use cases of PPSP 409 This section is not the to-do list for the WG, but for the 410 explanatory effect to show how PPSP could be used in practice. 412 5.1. Worldwide provision of live/VoD streaming 414 The content provider can increase live streaming coverage by 415 introducing PPSP in between different providers. This is quite 416 similar to the case described in CDNI [RFC6707][RFC6770]. 418 We suppose a scenario that there is only provider A(e.g,, in China) 419 providing the live streaming service in provider B(e.g., in USA) and 420 C(e.g., in Europe)'s coverage. Without PPSP, when a user(e.g., a 421 Chinese American) in USA requests the program to the tracker (which 422 is located in A's coverage), the tracker may generally return to the 423 user with a peer list including most of peers in China, because 424 generally most users are in China and there are only few users in 425 USA. This may affect the user experience. 427 But if we can use the PPSP tracker protocol to involve B and C in 428 the cooperative provision, as shown in Figure 2, even when the 429 streaming is not hot to attract many users in USA and Europe to view, 430 the tracker in A can optimally return the user with a peer list 431 including B's Super-nodes (SN for short) and C's SN to provide a 432 better user performance. 434 Furthermore User@B and User@C can exchange data (availability) with 435 these local SNs using the peer protocol. 437 5.2. Enabling CDN for P2P VoD streaming 439 Figure 3 shows the case of enabling CDN to support P2P VoD streaming 440 from different content providers by introducing PPSP inside CDN 441 overlays. It is similar to Figure 2 except that the intermediate SNs 442 are replaced by 3rd party CDN surrogates. The CDN nodes talk with 443 the different streaming systems (including trackers and peers)with 444 the same PPSP protocols. 446 Furthermore the interaction between the CDN nodes can be executed by 447 either existing (maybe proprietary) protocols or the PPSP Peer 448 protocol. The Peer protocol is useful for building new CDN systems 449 (e.g., operator CDN) supporting streaming in a low cost. 451 Note that for compatibility reason both HTTP streaming and P2P 452 streaming can be supported by CDN from the users' perspective. 454 +-------------------------------------------------------------------+ 455 | | 456 | +------------------+ | 457 | +------------>| A's Tracker |<----------+ | 458 | | +------------------+ | | 459 | Tracker| ^ ^ | | 460 | Protocol| Tracker| |Tracker |Tracker | 461 | | Protocol| |Protocol |Protocol | 462 | | | | | | 463 | | | | | | 464 | v v v v | 465 | +------+ Peer +------+ +------+ +------+ | 466 | | B's |<------->| B's | | C's | | C's | | 467 | | SN1 |Protocol | SN2 | | SN1 | | SN2 | | 468 | +------+ +------+ +------+ +------+ | 469 | ^ ^ ^ ^ | 470 | | | | | | 471 | | | Peer Protocol Peer Protocol| | | 472 | Peer | +-------------+ +--------------+ |Peer | 473 | Protocol| | | |Protocol| 474 | | | | | | 475 | | | | | | 476 | | | | | | 477 | v v v v | 478 | +------+ Peer +------+ +---------+ Peer +---------+ | 479 | | A's |<------> | B's | |A's |<------> |C's | | 480 | | User1|Protocol | User2| | User1 |Protocol | User2 | | 481 | +------+ +------+ +---------+ +---------+ | 482 | | 483 +-------------------------------------------------------------------+ 484 Figure 2 Cooperative Vendors Interaction 486 +-------------------------------------------------------------------+ 487 | | 488 | +-------------+ +--------------+ | 489 | +----->| A's Tracker | | B's Tracker |<---+ | 490 | | +-------------+ +--------------+ | | 491 | Tracker| ^ ^ ^ ^ | | 492 | Protocol| Tracker| |Tracker | |Tracker |Tracker | 493 | | Protocol| |Protocol| |Protocol |Protocol| 494 | | | | | | | | 495 | | | | | | | | 496 | v v | | v v | 497 | +------+ Peer +------+| | +------+Internal+------+ | 498 | | CDN |<------>| CDN || | | CDN |<-----> | CDN | | 499 | | Node1|Protocol| Node2|| | | Node3|Protocol| Node4| | 500 | +------+ +------+| | +------+ +------+ | 501 | ^ ^ | | ^ ^ | 502 | | | | | | | | 503 | | | Peer Protocol | | HTTP | | | 504 | Peer | +-------------+ | | +------+ | Peer | 505 | Procotol| | | | | Protocol |Protocol| 506 | | | +-+ | | | | 507 | | | | | | | | 508 | | | | | | | | 509 | v v v v v v | 510 | +------+ Peer +------+ +---------+ Peer +---------+ | 511 | | A's |<------> | A's | |B's |<------> |B's | | 512 | | User1|Protocol | User2| | User3 |Protocol | User4 | | 513 | +------+ +------+ +---------+ +---------+ | 514 | | 515 +-------------------------------------------------------------------+ 516 Figure 3 CDN Supporting P2P Streaming 518 5.3. Cross-screen streaming 520 In this scenario PC, STB/TV and mobile terminals from both fixed 521 network and mobile/wireless network share the streaming content. 522 With PPSP, peers can identify the types of access networks, average 523 load, peer abilities and get to know what content other peers have 524 even in different networks( potentially with the conversion of the 525 content availability expression in different networks) as shown in 526 Figure 4. 528 Such information will play an important role on selecting suitable 529 peers, e.g., a PC or STB is more likely to provide stable content 530 and a mobile peer within a high-load cell is unlikely to be selected, 531 which may otherwise lead to higher load on the base station. 533 +------------------------------------------------------------------+ 534 | | 535 | Tracker Protocol +---------+ Tracker Protocol | 536 | +-------------> | Tracker |<------------------+ | 537 | | +---------+ | | 538 | | ^ | | 539 | | | | | 540 | | | | | 541 | V | V | 542 | +------+ | +------------+ | 543 | | STB | Tracker Protocol |Mobile Phone| | 544 | +------+ | +------------+ | 545 | ^ | ^ | 546 | | | | | 547 | | | | | 548 | | V | | 549 | |Peer Protocol +---------+ Peer Protocol | | 550 | +-------------> | PC |<------------------+ | 551 | +---------+ | 552 | | 553 +------------------------------------------------------------------+ 554 Figure 4 Heterogeneous P2P Streaming with PPSP 556 5.4. Cache service supporting P2P streaming 558 In Figure 5, when peers request the P2P streaming data, the cache 559 nodes intercept the requests and ask for the frequently visited 560 content (or part of) on behalf of the peers. To do this, it asks the 561 tracker for the peer list and the tracker replies with external 562 peers in the peer list. After the cache nodes exchange data with 563 these peers, it can also act as a peer and report what it caches to 564 the tracker and serve inside requesting peers afterward. This 565 operation greatly decreases the inter-network traffic in many 566 conditions and increases user experience. 568 The cache nodes do not need to update their library when new 569 applications supporting PPSP are introduced, which reduces the cost. 571 +----------------------------------------------------------------+ 572 | | 573 | Tracker Protocol +---------+ | 574 | +----------------> | Tracker | | 575 | | +---------+ | 576 | | ^ | 577 | | | | 578 | | | Tracker Protocol | 579 | | | | 580 | | | | 581 | | +---------|-------------------------------------| 582 | | | V | 583 | | | +---------+ | 584 | | +----------|---> | Cache |<-------------------+ | 585 | | | | +---------+ Tracker/Peer| | 586 | | | Peer | Protocol | | 587 | | | Protocol | | | 588 | | | | | | 589 | | | | | | 590 | V V | V | 591 | +-----------+ | ISP Domain +------------+ | 592 | | External | | | Inside | | 593 | | Peer | | | Peer | | 594 | +-----------+ | +------------+ | 595 +----------------------------------------------------------------+ 596 Figure 5 Cache Service Supporting Streaming with PPSP 598 5.5. Proxy service supporting P2P streaming 600 5.5.1. Home networking scenario 602 For applications where the peer is not co-located with the Media 603 Player in the same device (e.g. the peer is located in a Home Media 604 Gateway), we can use a PPSP Proxy, as shown in figure 6. 606 As shown in figure 6, the PPSP Proxy terminates both the tracker and 607 peer protocol allowing the legacy presentation devices to access P2P 608 streaming content. In figure 6 the DLNA protocol [DLNA] is used in 609 order to communicate with the presentation devices thanks to its 610 wide deployment. Obviously, other protocols can also be used. 612 +---------------------------------------------------------------+ 613 | | 614 | Tracker Protocol +--------+ | 615 | +----------------> | Tracker| | 616 | | +--------+ | 617 | | ^ | 618 | | | | 619 | | | Tracker Protocol | 620 | | | | 621 | | +---------|------------------------------------| 622 | | | V | 623 | | | +---------+ | 624 | | +----------|---> | PPSP |<-------------------+ | 625 | | | | | Proxy | DLNA | | 626 | | | Peer | +---------+ Protocol | | 627 | | | Protocol| | | 628 | | | | | | 629 | V V | V | 630 | +-----------+ | Home Domain +-----------+ | 631 | | External | | |DLNA Pres.| | 632 | | Peer | | |Devices | | 633 | +-----------+ | +-----------+ | 634 +---------------------------------------------------------------+ 635 Figure 6 Proxy service Supporting P2P Streaming 637 5.5.2. Browser-based HTTP streaming 639 P2P Plug-ins are often used in browser-based environment in order to 640 stream content. With P2P plug-ins, HTTP streaming can be turned into 641 a de facto P2P streaming. From the browser (and hence the user) 642 perspective, it's just HTTP based streaming but the PPSP capable 643 plug-in can actually accelerate the process by leveraging streams 644 from multiple sources/peers [P2PYoutube]. In this case the plug-ins 645 behave just like the proxy. 647 6. Requirements of PPSP 649 This section enumerates the requirements that should be considered 650 when designing PPSP. 652 6.1. Basic Requirements 654 PPSP.REQ-1: Each peer MUST have a unique ID (i.e., peer ID). 656 It's a basic requirement for a peer to be uniquely identified in a 657 P2P streaming system so that other peers or tracker can refer to 658 the peer by ID. 660 Note that a peer can join multiple swarms with a unique ID, or 661 change swarm without changing its ID. 663 PPSP.REQ-2: The streaming content MUST be uniquely identified by a 664 swarm ID. 666 A swarm refers to a group of peers sharing the same streaming 667 content. A swarm ID uniquely identifies a swarm. The swarm ID can 668 be used in two cases: 1) a peer requests the tracker for the peer 669 list indexed by a swarm ID; 2) a peer tells the tracker about the 670 swarms it belongs to. 672 PPSP.REQ-3: The streaming content MUST be partitioned into chunks. 674 PPSP.REQ-4: Each chunk MUST have a unique ID (i.e., chunk ID) in the 675 swarm. 677 Each chunk must have a unique ID in the swarm so that the peer can 678 understand which chunks are stored in which peers and which chunks 679 are requested by other peers. 681 6.2. Operation & Management Requirements 683 This section lists some operation and management requirements 684 following the checklist presented by Appendix A in [RFC5706]. 686 6.2.1. Operation Considerations 688 PPSP.OAM.REQ-1: PPSP MUST be sufficiently configurable for 689 installation and initial setup. 691 According to basic requirements, when setting up PPSP, content 692 provider should generate chunk IDs and swarm ID for each streaming 693 content. At least one original content server and one tracker are 694 configured and setup. Content provider then should publish this 695 information typically by creating web links. 697 Content provider can deploy peer functions in either streaming 698 clients or third-party entities like proxy. 700 PPSP.OAM.REQ-2: PPSP MUST implement a set of configuration 701 parameters with default values. 703 A set of parameters such as chunk size, hashing algorithms 704 generating IDs, needs to be implemented by PPSP for configuration 705 purpose. Default values of these parameters should be set to ensure 706 interoperability in most situations. 708 PPSP.OAM.REQ-3: PPSP MUST be capable of controlling traffic load to 709 existing networks. 711 PPSP needs to be managed to reduce traffic load to ISPs by 712 selecting an appropriate set of content sources. For example, PPSP 713 tracker can generate a peer list with the help of traffic 714 optimization services, e.g. ALTO [I-D.ietf-alto-protocol]. 716 PPSP.OAM.REQ-4: PPSP MUST support diagnostic operations. 718 Mechanisms must be supported by PPSP to verify correct operations. 719 PPSP tracker should collect the status of the peers including 720 peer's activity, obtained chunks in due time, etc. Such information 721 can be used to monitor the streaming behavior of PPSP. 723 PPSP.OAM.REQ-5: PPSP MUST facilitate achieving quality acceptable to 724 streaming application. 726 There are basic quality requirements for streaming systems. Setup 727 time to receive a new streaming channel or to switch between 728 channels should be reasonably small. End to end delay, which 729 consists of the time between content generation (e.g., a camera) 730 and content consumption (e.g., a monitor), will become critical in 731 case of live streaming especially in provisioning of sport events 732 where end to end delay of 1 minute and more are not acceptable. 734 For instance, the tracker and peer protocol can carry quality 735 related parameters (e.g. video quality and delay requirements) 736 together with the priorities of these parameters in addition to the 737 measured QoS situation (e.g., performance, available uplink 738 bandwidth) of content providing peers. 740 When experiencing downgrade of streaming performance, PPSP should 741 try techniques such as scalable streaming for acceptable quality. 743 6.2.2. Management Considerations 745 PPSP.OAM.REQ-6: PPSP MUST support remote management using 746 centralized server, i.e. PPSP tracker. A basic set of management 747 information MUST be implemented by PPSP tracker. 749 Due to large-scale peer network, PPSP tracker should remotely 750 collect information from peers for management purpose. Peer 751 information can be collected via PPSP tracker protocol and/or other 752 existing standard IETF protocols. The overall management 753 information can be exposed by PPSP tracker using existing standard 754 IETF protocols. 756 The minimum set of management objects should include swarm 757 information such as content characteristics, rate limit, track 758 information such as swarm list, log event, peer information such as 759 peer activity, chunk statistics, log event. 761 PPSP.OAM.REQ-7: PPSP MUST support fault monitoring including peer 762 and server health, as well as streaming behavior of peers. 764 Peer and server health will at least include node activity and 765 connectivity especially for peers behind NAT. As mentioned in 766 OAM.REQ-4, streaming behavior of peer can be learnt from chunk 767 distribution information. 769 PPSP.OAM.REQ-8: PPSP MUST support configuration management to define 770 the configuration parameters. 772 Referring to OAM.REQ-2, a set of configurable parameters related to 773 chunk generation in PPSP setup stage can be defined by content 774 providers via a management interface to content servers. 776 PPSP.OAM.REQ-9: PPSP MUST support accounting management when content 777 provider wants to charge clients for certain content. 779 An example of accounting management is collecting the bandwidth 780 usage of different peers for certain swarm ID. 782 PPSP.OAM.REQ-10: PPSP MUST support performance management with 783 respect to streaming performance based on chunk distribution 784 statistics, network load, track and peer monitor. 786 PPSP.OAM.REQ-11: PPSP MUST support security management. See section 787 of "Security Considerations" in this document. 789 6.3. PPSP Tracker Protocol Requirements 791 PPSP.TP.REQ-1: The tracker protocol MUST allow the peer to solicit 792 a peer list in a swarm generated and possibly tailored by the 793 tracker in a query and response manner. 795 The tracker request message may include the requesting peer's 796 preference parameter (e.g. preferred number of peers in the peer 797 list) or preferred downloading bandwidth. The tracker will then be 798 able to select an appropriate set of peers for the requesting peer 799 according to the preference. 801 The tracker may also generate the peer list with the help of 802 traffic optimization services, e.g. ALTO [I-D.ietf-alto-protocol]. 804 PPSP.TP.REQ-2: The tracker protocol MUST report the peer's activity 805 in the swarm to the tracker. 807 PPSP.TP.REQ-3: The tracker protocol MUST take the frequency of 808 messages and efficient use of bandwidth into consideration, when 809 communicating chunk availability information. 811 For example, the chunk availability information between peer and 812 tracker can be presented in a compact method, e.g., to express a 813 sequence of continuous "1" more efficiently. 815 PPSP.TP.REQ-4: The tracker protocol MUST have a provision for 816 tracker to authenticate the peer. 818 This ensures that only the authenticated users can access the 819 original content in the P2P streaming system. 821 PPSP.TP.REQ-5: PPSP tracker MUST be robust. 823 When centralized tracker fails, the P2P streaming system should 824 still work by supporting distributed trackers. 826 6.4. PPSP Peer Protocol Requirements 828 PPSP.PP.REQ-1: The peer protocol MUST allow the peer to solicit the 829 chunk information from other peers in a query and response manner. 831 PPSP.PP.REQ-2: The chunk information exchanged between a pair of 832 peers MUST NOT be passed to other peers, unless the chunk 833 information is validated (e.g. preventing hearsay and DoS attack). 835 PPSP.PP.REQ-3: The peer protocol MUST allow the peer to solicit an 836 additional list of peers to that received from the tracker. 838 It is possible that a peer may need additional peers for certain 839 streaming content. Therefore, it is allowed that the peer 840 communicates with other peers in the current peer list to obtain an 841 additional list of peers in the same swarm. 843 PPSP.PP.REQ-4: When used for soliciting additional list of peers, 844 the peer protocol MUST contain swarm-membership information of the 845 peers that have explicitly indicated they are part of the swarm, 846 verifiable by the receiver. 848 PPSP.PP.REQ-5: The additional list of peers MUST only contain peers 849 which have been checked to be valid and online recently (e.g., 850 preventing hearsay and DoS attack). 852 PPSP.PP.REQ-6: The peer protocol MUST report the peer's chunk 853 availability update. 855 Due to the dynamic change of the buffered streaming content in each 856 peer and the frequent join/leave of peers in the swarm, the 857 streaming content availability among a peer's neighbors (i.e., the 858 peers known to a peer by getting the peer list from either tracker 859 or peers) always changes and thus requires being updated on time. 860 This update should be done at least on demand. For example, when a 861 peer requires finding more peers with certain chunks, it sends a 862 message to some other peers in the swarm for streaming content 863 availability update. Alternatively, each peer in the swarm can 864 advertise its streaming content availability to some other peers 865 periodically. However, the detailed mechanisms for this update such 866 as how far to spread the update message, how often to send this 867 update message, etc. should leave to the algorithms, rather than 868 protocol concerns. 870 PPSP.PP.REQ-7: The peer protocol MUST take the frequency of messages 871 and efficient use of bandwidth into consideration, when 872 communicating chunk information. 874 For example, the chunk availability information between peers can 875 be presented in a compact method. 877 PPSP.PP.REQ-8: The peer protocol MUST exchange additional 878 information, e.g., status about the peers. 880 This information can be, for instance, information about the access 881 link or information about whether a peer is running on battery or 882 is connected to a power supply. With such information, a peer can 883 select more appropriate peers for streaming. 885 7. Security Considerations 887 This document discusses the problem statement and requirements 888 around P2P streaming protocols without specifying the protocols. 889 However we believe it is important for the reader to understand 890 areas of security introduced by the P2P nature of the proposed 891 solution. The main issue is the usage of un-trusted entities (peers) 892 for service provisioning. For example, malicious peers/trackers may: 894 - Originate denial of service (DOS) attacks to the trackers by 895 sending large amount of requests with the tracker protocol; 897 - Originate fake information on behalf of other peers; 899 - Originate fake information about chunk availability; 900 - Originate reply instead of the regular tracker (man in the middle 901 attack); 903 - leak private information about other peers or trackers. 905 We list some important security requirements for PPSP protocols as 906 below: 908 PPSP.SEC.REQ-1: PPSP MUST support closed swarms, where the peers are 909 authenticated or in a private network. 911 This ensures that only the trusted peers can access the original 912 content in the P2P streaming system. This can be achieved by 913 security mechanisms such as peer authentication and/or key 914 management scheme. 916 Another aspect is that confidentiality of the streaming content in 917 PPSP need to be supported. In order to achieve this, PPSP should 918 provide mechanisms to encrypt the data exchange among the peers. 920 PPSP.SEC.REQ-2: Integrity of the streaming content in PPSP MUST be 921 supported to provide a peer with the possibility to identify 922 unauthentic content (undesirable modified by other entities rather 923 than its genuine source). 925 In a P2P live streaming system a polluter can introduce corrupted 926 chunks. Each receiver integrates into its playback stream the 927 polluted chunks it receives from its neighbors. Since the peers 928 forwards chunks to other peers, the polluted content can 929 potentially spread through the P2P streaming network. 931 The PPSP protocol specifications will document the expected 932 threats(and how they will be mitigated by each protocol) and also 933 considerations on threats and mitigations when combining both 934 protocols in an application. This will include privacy of the users 935 and protection of the content distribution. 937 PPSP.SEC.REQ-3: The security mechanisms in PPSP, such as key 938 management and checksum distribution MUST scale well in P2P 939 streaming systems. 941 8. IANA Considerations 943 This document has no actions for IANA. 945 9. Acknowledgments 947 Thank you to J.Seng, G. Camarillo, R. Yang,C. Schmidt, R. Cruz, Y. 948 Gu, A.Bakker and S. Previdi for contribution to many sections of 949 this draft. Thank you to C. Williams,V. Pascual and L. Xiao for 950 contributions to PPSP requirements section. 952 We would like to acknowledge the following people who provided 953 review, feedback and suggestions to this document: M. Stiemerling, D. 954 Bryan, E. Marocco, V. Gurbani, R. Even, H. Zhang, D. Zhang, J. 955 Lei, H.Song, X.Jiang, J.Seedorf, D.Saumitra, A.Rahman, J.Pouwelse, W.Eddy, 956 B. Claise, D. Harrington, J. Arkko and all the AD reviewers. 958 This document was prepared using 2-Word-v2.0.template.dot. 960 10. References 962 10.1. Normative References 964 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 965 Requirement Levels", BCP 14, RFC 2119, March 1997. 967 [RFC6707] B. Niven-Jenkins, "Content Distribution Network 968 Interconnection (CDNI) Problem Statement", RFC 6707, Sep 2012. 970 [RFC6770] G. Bertrand, "Use Cases for Content Delivery Network 971 Interconnection", RFC6770, Nov 2012. 973 [RFC5706] D. Harrington, "Guidelines for Considering Operations 974 and Management of New Protocols and Protocol Extensions", RFC5706, 975 Nov 2009. 977 10.2. Informative References 979 [Cisco] Cisco Visual Networking Index: Forecast and Methodology, 980 2009-2014, 981 http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns 982 705/ns827/white_paper_c11- 983 481360_ns827_Networking_Solutions_White_Paper.html 985 [VoD] Y. Huang et al,Challenges,"Design and Analysis of a Large- 986 scale P2P-VoD System", Sigcomm08. 988 [ByteMobile]http://www.bytemobile.com/news- 989 events/2012/archive_230212.html 991 [Mobile Streaming1] Streaming to Mobile Users in a Peer-to-Peer 992 Network,J. Noh etal,MOBIMEDIA '09. 994 [Mobile Streaming2] J.Peltotaloetal.,"A real-time Peer-to-Peer 995 streaming system for mobile networking environment",in Proceedings 996 of the INFOCOM and Workshop on Mobile Video Delivery (MoVID '09). 998 [Hybrid CDN P2P]D. Xu et al, "Analysis of a CDN-P2Phybrid 999 architecture for cost-effective streaming mediadistribution," 1000 SpringerMultimediaSystems, vol.11, no.4, pp.383-399, 2006. 1002 [PPTV] http://www.pptv.com 1004 [PPStream] http://www.ppstream.com 1006 [DLNA] http://www.dlna.org 1008 [P2PYoutube] https://addons.opera.com/en/extensions/details/p2p- 1009 youtube/ 1011 [I-D.ietf-alto-protocol] R.Alimi et al, "ALTO Protocol", draft-ietf- 1012 alto-protocol-13 (work in progress), Sep. 2012. 1014 Authors' Addresses 1016 Yunfei Zhang 1017 China Mobile Communication Corporation 1018 zhangyunfei@chinamobile.com 1020 Ning Zong 1021 Huawei 1022 zongning@huawei.com