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