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