idnits 2.17.1 draft-seedorf-ppsp-design-considerations-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 20, 2011) is 4755 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPSP J. Seedorf 3 Internet-Draft M. Stiemerling 4 Intended status: Informational NEC 5 Expires: October 22, 2011 M. Mellia 6 Politecnico di Torino 7 R. Lo Cigno 8 C. Kiraly 9 University of Trento 10 April 20, 2011 12 Design Considerations for a Peer-to-Peer Streaming Protocol 13 draft-seedorf-ppsp-design-considerations-02 15 Abstract 17 Streaming video on P2P overlays puts extremely high demands and 18 stress on the underlying network, especially in case of TV and live 19 streaming. The EU research project NAPA-WINE has devised an overall 20 architecture for live video streaming that supports the needs of the 21 users and content providers, while being respective of network-level 22 needs, as reducing inter-AS traffic using ALTO-like services. In 23 this document, we describe generic elements of this software 24 architecture for P2P live streaming and derive the corresponding 25 implications for standardizing a Peer-to-Peer streaming protocol. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 22, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. An Architecture for a P2P-based Live Streaming Application . . 5 63 2.1. Application Layer . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Topology Management . . . . . . . . . . . . . . . . . . . 5 65 2.3. Chunk Scheduling . . . . . . . . . . . . . . . . . . . . . 6 66 2.4. Monitoring Layer . . . . . . . . . . . . . . . . . . . . . 7 67 2.5. Messaging Layer . . . . . . . . . . . . . . . . . . . . . 7 68 2.6. Interaction with ALTO . . . . . . . . . . . . . . . . . . 8 69 3. Summary of Considerations for PPSP Protocol Design . . . . . . 9 70 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 73 7. Informative References . . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 In recent years, Peer-to-peer (P2P) technology became increasingly 79 popular for video streaming applications, including TV services 80 (P2P-TV). Examples of commercial P2P-TV include SopCast, TVAnts, 81 PPLive, UUSee, and TVUplayer. The interest of the research and 82 standardization communities, content providers and network operators 83 is also on the rise. Content providers see a novel opportunity to 84 reach users, but at the same time they are concerned about the 85 threats posed to their standard business models. Network operators 86 are mainly worried by the stress posed by such a bandwidth-hungry and 87 delay sensitive application on their infrastructure. The research 88 community is stimulated by the opportunities offered by live P2P 89 distribution and broadcasting, looking both for novel technical 90 solutions and innovative business models. 92 NAPA-WINE (Network Aware P2P-TV Application over WIse NEtworks) is a 93 three years project (STREP) within the 7-th Research Framework of the 94 European Commission whose goal is finding innovative solutions for 95 P2P live streaming to meet opportunities envisaged by content 96 providers while soothing worries of network operators 97 [refs.napawebpage]. 99 In a P2P-TV system, a source divides the video stream into chunks of 100 data, which are exchanged among nodes to distribute them to all 101 participating peers. Peers form an overlay topology at the 102 application layer, where neighbor peers are connected and exchange 103 chunks using the underlying IP network. The IP and overlay layer are 104 both "network" layers in that they both perform routing and 105 forwarding of the data: packets in the IP layer and chunks (normally 106 a sequence of packets) in the overlay. In this context, the NAPA- 107 WINE project has developed an innovative, network cooperative P2P 108 architecture that explicitly targets the optimization of the quality 109 perceived by the users while minimizing the impact on the underlying 110 transport network. Our architecture does not impose any structure on 111 the overlay topology, which can be any type of generic mesh. The 112 video distribution is chunk-based, but chunk construction is free 113 enough to accommodate anything from a single video frame (even less 114 if required) to large swaths of a video in case of nearly on-demand 115 applications. The focus is on the design of a system empowering 116 future P2P High Quality TV, a system where a source peer produces the 117 video stream, chops it into chunks, and injects them in the overlay 118 where peers cooperate to distribute them, without the need for the 119 source to have enormous resources and bandwidth to support the 120 service. 122 In this document, we summarize our architecture for P2P live 123 streaming (a more detailed description can be found in 125 [refs.napa-architecture]). The goal of this draft is to derive the 126 implications for standardizing a P2P-based streaming protocol from 127 the aforemetioned architecture. We thus highlight key design 128 considerations for a P2P-based streaming protocol which we believe 129 are important input to the IETF PPSP working group. 131 An open-source implementation of this P2P live streaming architecture 132 has been released, entitled "WINESTREAMER". The latest release of 133 the WINESTREAMER software can be retrieved at [refs.winestreamer]. 135 2. An Architecture for a P2P-based Live Streaming Application 137 The architecture we developed is based on five main building blocks: 139 o Application Layer 141 o Topology Management 143 o Chunk Scheduling 145 o Monitoring Layer 147 o Messaging Layer 149 In addition, our architecture contains an external ALTO interface 150 that can support the topology management providing information that 151 cannot be measured at the application level. In the following we 152 briefly outline the role and key features of each building block. 154 2.1. Application Layer 156 The Application Layer (or User Layer) is mainly responsible for of 157 video encoding and its packaging into chunks (at the source) and de- 158 chunkization and decoding at receivers. Standard encoding tools like 159 ffmpeg can be used by the User Layer, whose goal is not implementing 160 a proprietary video encoder, but supporting as many as possible 161 standard formats (MPEG1/2/4, H.264, etc.). Depending on the type of 162 video source this may include analog/digital conversion, encoding and 163 any other video manipulation that the content provider whishes to do, 164 like advertising introduction and similar. 166 The standardization of the application layer is out-of-scope for IETF 167 PPSP work other than considerations on how to express and transport 168 metadata information about the content. 170 2.2. Topology Management 172 A P2P-TV client needs to communicate efficiently with other peers to 173 receive and redistribute the huge amount of information embedded in a 174 video stream. Information must arrive in nearly real-time and with 175 small delay variation. The application goal is then to deliver all 176 the video information to all peers in the system in the smallest 177 possible amount of time. One of the key enabling factors is who are 178 the peers to communicate with, i.e. the neighborhood selection. 180 The overlay network in P2P systems is the result of a distributed 181 algorithm that builds and maintains the neighborhood at each peer. 182 When a peer joins the system, it selects an initial set of neighbors, 183 then the set of neighbors of every node in the system is dynamically 184 optimized over time. The bootstrapping phase can be helped by the 185 source or a web server where the user selects a channel, which can 186 behave as a bit-torrent like tracker. The maintenance of the 187 topology is based on a gossiping protocol that enables discovery of 188 peers in the overlay. Once peers are discovered, the optimal 189 topology management is obtained through an topology manager which 190 chooses which peers to connect to. 192 IMPLICATIONS ON STANDARDIZATION: 194 o A tracker protocol is required that supports the goals of the 195 topology management 197 o The topology management algorithm can be standardized, but this 198 would probably be beyond the scope of the PPSP WG 200 o The definition of information about the employed topology 201 management and the exchange as part of the PPSP WG can be 202 standardized 204 2.3. Chunk Scheduling 206 Strictly related to topology management is the problem of chunk 207 trading. The goal of chunk trading is receiving the stream smoothly 208 (and with small delay) and to cooperate in the distribution 209 procedure. 211 Chunks transferring is the operation that most affects performance 212 and network friendliness. It includes protocol and algorithmic 213 problems. First of all, peers need to exchange information about 214 their current status to enable scheduling decisions. The information 215 exchanged refers to the state of the peer with respect to the flow, 216 i.e., a map of which chunks are needed by a peer to smoothly playout 217 the stream. This task means i) sending buffer maps to other nodes 218 with the proper timing, ii) receiving them from other nodes and 219 merging the information in the local buffer map data base, iii) 220 negotiating if this and other information should be spread by 221 gossiping protocols or not, and to which depth it should spread in 222 the topology. 224 Besides the buffer map exchange, the signaling includes Offer/ 225 Request/Select primitives used to trade chunks. These messages can 226 be piggybacked on chunks for efficiency. Another key protocol 227 decision is about "Pushing" or "Pulling" information. A chunk is 228 pushed when the peer owning the chunk decides to offer it to some 229 other peer, while it is pulled when a peer needing the chunk requests 230 it from another peer. From a theoretical point of view, as shown in 232 [refs.opt-scheduling], pushing is more effective. Regardless of the 233 protocol and the signaling strategy used, the core of a scheduler is 234 the algorithm to choose the chunks to be exchanged and the peers to 235 communicate with. Many different strategies have been studied, 236 including both fundamental algorithms and their adaptation to 237 heterogeneous scenarios, multiple sub-streams etc. 239 IMPLICATIONS ON STANDARDIZATION: 241 o The PPSP protocol design should allow to operate either with a 242 push or pull regime 244 o The PPSP protocol design should allow to select if push or pull is 245 used in the PPSP system during runtime 247 o The PPSP protocol design should allow to employ multiple chunk 248 scheduling algorithms with the same protocol 250 2.4. Monitoring Layer 252 Beside the information provided by e.g. an ALTO Server, both the 253 chunk scheduler and the overlay manager can exploit timely 254 information about the quality of the connectivity between peers 255 collected in real time by monitoring modules. This includes, but is 256 not limited to, the distance and the available bandwidth between two 257 peers, or the presence of Network Address Translation (NAT). The 258 Monitoring Layer may employ passive or active measurement. Passive 259 measurements are performed by observing the messages that are 260 exchanged between peers. Active measurements craft special probe 261 messages which are sent to other peers at the discretion of the 262 Monitoring Layer. Monitoring the network conditions is important for 263 the peer-to-peer streaming application in order to judge the current 264 state of the surrounding network environment 266 IMPLICATIONS ON STANDARDIZATION: 268 o The PPSP protocol should allow the exchange of monitoring status 269 information (e.g., in the spirit of "Do you see what I see?" 270 [refs.dywis]) 272 o The PPSP protocol should support active and passive measurements 273 between peers 275 2.5. Messaging Layer 277 The Messaging Layer offers primitives to other modules for sending 278 and receiving data to/from other peers. It provides an abstract 279 interface to transport protocols (UDP/TCP) and the corresponding 280 service access points offered by the operating system by extending 281 their capabilities and providing an application level addressing, 282 i.e., assigning a unique identifier to each peer. For example, it 283 provides the ability to send a chunk to another peer, which has to be 284 segmented and then reassembled to fit into UDP datagrams. The 285 messaging layer also provides an interface to the monitoring module 286 invoked for passive measurements: whenever a message is sent or 287 received an indication will be given to the monitoring module, which 288 can update its statistics. The last important feature of the 289 messaging layer is mechanisms for the traversal of NAT boxes. 291 IMPLICATIONS ON STANDARDIZATION: 293 o The PPSP protocol should allow to negotiate or select different 294 transport protocols, e.g., between plain TCP and LEDBAT. 296 o The PPSP protocol or framework should support peers in NAT 297 traversal. 299 2.6. Interaction with ALTO 301 Application Layer Traffic Information (ALTO) [refs.alto] is an 302 important means for improving the resource provider selection in P2P 303 applications. The goal of an ALTO service is to provide applications 304 with useful information (e.g. for P2P neighbor selection) which these 305 applications cannot measure themselves [RFC5693]. Simulations have 306 shown that the usage of information provided by an ALTO service can 307 reduce operational costs associated with the transmission of P2P live 308 streaming traffic [refs.etm2010]. The topology management in the 309 NAPA-WINE architecture therefore fully supports ALTO guidance through 310 the integration of an ALTO client within the topology manager. 311 Further, the information retrieved via the integrated ALTO client can 312 be used in neighbor selection, i.e. peers select the links to other 313 peers in their neighbor list (partially) based on ALTO information. 315 IMPLICATIONS ON STANDARDIZATION: 317 o The PPSP protocol should allow peers to interact with an ALTO 318 server and to retrieve ALTO information. 320 o The PPSP protocol should enable the use of ALTO information in 321 peer selection. 323 3. Summary of Considerations for PPSP Protocol Design 325 In this section we summarize the design considerations we derived 326 from our experience in designing a P2P live streaming system and 327 which we motivated in the previous section. 329 DESIGN CONSIDERATIONS FOR A PPSP PROTOCOL: 331 o A tracker protocol is required that supports the goals of the 332 topology management 334 o The topology management algorithm can be standardized, but this 335 would probably be beyond the scope of the PPSP WG 337 o The definition of information about the employed topology 338 management and the exchange as part of the PPSP WG can be 339 standardized 341 o The PPSP protocol design should allow to operate either with a 342 push or pull regime 344 o The PPSP protocol design should allow to select if push or pull is 345 used in the PPSP system during runtime 347 o The PPSP protocol design should allow to employ multiple chunk 348 scheduling algorithms with the same protocol 350 o The PPSP protocol should allow the exchange of monitoring status 351 information (e.g., in the spirit of "Do you see what I see?" 352 [refs.dywis]) 354 o The PPSP protocol should support active and passive measurements 355 between peers 357 o The PPSP protocol should allow to negotiate or select different 358 transport protocols, e.g., between plain TCP and LEDBAT. 360 o The PPSP protocol or framework should support peers in NAT 361 traversal. 363 o The PPSP protocol should allow peers to interact with an ALTO 364 server and to retrieve ALTO information. 366 o The PPSP protocol should enable the use of ALTO information in 367 peer selection. 369 4. Conclusions 371 Video Streaming applications exploiting the P2P communication 372 paradigm are a commercial reality, but their overall architecture is 373 still biased by file-sharing applications and they operate without 374 any coordination with the IP network, often resulting in poor, even 375 wasteful resource usage. This will prevent them to support High 376 Quality TV in the future, or to make the transition to High 377 Definition, which will require several Mbit/s per peer. 379 This document presented the NAPA-WINE architecture for a P2P-TV 380 system, which has been developed with the goal of efficiency and 381 cooperation between the application and both the network operators 382 and the content providers. Prototypes of the peers and system are 383 already running on the Internet and are demonstrated at major venues 384 [refs.demo-iptcomm2010] [refs.demo-p2p2010] [refs.demo-infocom2011]. 386 In addition, an open-source implementation of the P2P live streaming 387 architecture presented in this document has been released, entitled 388 "WINESTREAMER". The latest release of the WINESTREAMER software can 389 be retrieved at [refs.winestreamer]. 391 The overlay topology management and the chunk scheduling of 392 information have been identified as important features for the 393 application to be network-friendly. The first function enables 394 building efficient and rational overlay topologies that are correctly 395 mapped on top of the transport network structure (e.g., considering 396 minimal number of hops between neighbors, locality w.r.t. Autonomous 397 Systems, etc.). The second function guarantees that the network 398 capacity is exploited without waste (e.g., by minimizing 399 retransmissions and pursuing an efficient distribution of chunks, 400 etc.). 402 Based on our experience in designing and implementing a P2P live 403 streaming system, we highlighted key implications for 404 standardization. We believe that these key design considerations we 405 derived based on our architecture will be important input to the IETF 406 PPSP working group for standardizing a P2P live streaming protocol. 408 5. Security Considerations 410 Security considerations will be detailed in future versions of this 411 draft. 413 6. Acknowledgements 415 The authors would like to thank all the people participating in NAPA- 416 WINE and contributing to the project success with their work and 417 research. 419 Jan Seedorf, Marco Mellia, Renato Lo Cigno, and Csaba Kiraly are 420 partially supported by the NAPA-WINE project (Network-Aware P2P-TV 421 Application over Wise Networks, http://www.napa-wine.org), a research 422 project supported by the European Commission under its 7th Framework 423 Program (contract no. 214412). The views and conclusions contained 424 herein are those of the authors and should not be interpreted as 425 necessarily representing the official policies or endorsements, 426 either expressed or implied, of the NAPA-WINE project or the European 427 Commission. 429 Martin Stiemerling is partially supported by the COAST project 430 (COntent Aware Searching, retrieval and sTreaming, 431 http://www.coast-fp7.eu), a research project supported by the 432 European Commission under its 7th Framework Program (contract no. 433 248036). The views and conclusions contained herein are those of the 434 authors and should not be interpreted as necessarily representing the 435 official policies or endorsements, either expressed or implied, of 436 the COAST project or the European Commission. 438 7. Informative References 440 [refs.napa-architecture] 441 Birke, R., Leonardi, E., Mellia, M., Bakay, A., Szemethy, 442 T., Kiraly, C., Lo Cigno, R., Mathieu, F., Muscariello, 443 L., Niccolini, S., Seedorf, J., and G. Tropea, 444 "Architecture of a Network-Aware P2P-TV Application: the 445 NAPA-WINE Approach", IEEE Communication Magazine, to 446 appear. 448 [refs.opt-scheduling] 449 Abeni, L., Kiraly, C., and R. Lo Cigno, "On the Optimal 450 Scheduling of Streaming Applications in Unstructured 451 Meshes", IFIP Networking 2009. 453 [refs.demo-iptcomm2010] 454 Seedorf, J., Niccolini, S., Lo Cigno, R., and C. Kiraly, 455 "Prototypical Implementation of ALTO Client and ALTO 456 Server and Integration into a P2P Live Streaming 457 Software", Demonstration, IPTComm 2010. 459 [refs.demo-p2p2010] 460 Abeni, L., Bakay, A., Biazzini, M., Birke, R., Leonardi, 461 E., Lo Cigno, R., Kiraly, C., Mellia, M., Niccolini, S., 462 Seedorf, J., Szemethy, T., and G. Tropea, "Network 463 Friendly P2P-TV: The Napa-Wine Approach", Live 464 Demonstration and Extended Abstract, IEEE P2P 2010. 466 [refs.demo-infocom2011] 467 Abeni, L., Bakay, A., Birke, R., Birke, R., Leonardi, E., 468 Lo Cigno, R., Kiraly, C., Mellia, M., Niccolini, S., 469 Seedorf, J., Szemethy, T., and G. Tropea, 470 "WineStreamer(s): Flexible P2P-TV Streaming Applications", 471 Live Demonstration and Extended Abstract, IEEE INFOCOM 472 2011. 474 [refs.dywis] 475 Miao, X., Schulzrinne, H., Singh, V., and Q. Deng, 476 "Distributed Self Fault-Diagnosis for SIP Multimedia 477 Applications", Springer Real-Time Mobile Multimedia 478 Services, 2007. 480 [refs.etm2010] 481 Seedorf, J., Niccolini, S., Stiemerling, M., Ferranti, E., 482 and R. Winter, "Quantifying Operational Cost-Savings 483 through ALTO-Guidance for P2P Live Streaming", 3rd 484 Workshop on Economic Traffic Management (ETM 2010), LNCS 485 6236. 487 [refs.alto] 488 Peterson, J., Gurbani, V., Marocco, E., and et. al., "IETF 489 ALTO WG charter", 490 https://datatracker.ietf.org/wg/alto/charter/. 492 [refs.winestreamer] 493 "Napa-Wine Winestreamer latest release", http:// 494 www.napa-wine.eu/cgi-bin/twiki/view/Public/ 495 NapaWineShowRoom. 497 [refs.napawebpage] 498 "Napa-Wine Project Website", http://www.napa-wine.eu. 500 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 501 Optimization (ALTO) Problem Statement", RFC 5693, 502 October 2009. 504 Authors' Addresses 506 Jan Seedorf 507 NEC Laboratories Europe, NEC Europe Ltd. 508 Kurfuersten-Anlage 36 509 Heidelberg 69115 510 Germany 512 Phone: +49 (0) 6221 4342 221 513 Email: jan.seedorf@neclab.eu 514 URI: http://www.nw.neclab.eu 516 Martin Stiemerling 517 NEC Laboratories Europe / University of Goettingen 518 Kurfuersten-Anlage 36 519 Heidelberg 69115 520 Germany 522 Phone: +49 (0) 6221 4342 113 523 Email: martin.stiemerling@neclab.eu 524 URI: http://ietf.stiemerling.org 526 Marco Mellia 527 Politecnico di Torino, Italy 528 Corso Duca degli Abruzzi 24 529 Torino 10129 530 ITALY 532 Phone: 533 Email: mellia@tlc.polito.it 534 URI: 536 Renato Lo Cigno 537 University of Trento 538 Via Sommarive 14 539 Povo 38123 540 ITALY 542 Phone: 543 Email: locigno@disi.unitn.it 544 URI: 546 Csaba Kiraly 547 University of Trento 548 Via Sommarive 14 549 Povo 38123 550 ITALY 552 Phone: 553 Email: kiraly@disi.unitn.it 554 URI: