idnits 2.17.1 draft-zhang-ppsp-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack an IETF Trust Provisions of 28 Dec 2009, Section 6.b Copyright Notice. 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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.) ** There are 11 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 198 has weird spacing: '...UDP is used ...' == Line 201 has weird spacing: '... These rules...' == Line 279 has weird spacing: '...Because there...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 23, 2009) is 5541 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 389 looks like a reference -- Missing reference section? '2' on line 391 looks like a reference -- Missing reference section? '3' on line 393 looks like a reference -- Missing reference section? '4' on line 395 looks like a reference -- Missing reference section? '5' on line 397 looks like a reference -- Missing reference section? '6' on line 399 looks like a reference -- Missing reference section? '7' on line 401 looks like a reference -- Missing reference section? '8' on line 403 looks like a reference -- Missing reference section? '9' on line 405 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPSP Yunfei. Zhang 2 Internet Draft China Mobile 3 Intended status: Standards Track February 23, 2009 4 Expires: August 19, 2009 6 Problem Statement of P2P Streaming Protocol (PPSP) 7 draft-zhang-ppsp-problem-statement-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 This Internet-Draft will expire on August 23, 2009. 31 Copyright Notice 33 Copyright (C) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. 43 Abstract 45 The document outlines the problem statement of peer to peer streaming 46 applications and the definition and scope of peer to peer streaming 47 protocol. 49 Conventions used in this document 51 In examples, "C:" and "S:" indicate lines sent by the client and 52 server respectively. 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [1]. 58 Table of Contents 60 1. Introduction................................................2 61 2. Problem Statement of P2P streaming Applications..............3 62 3. Peer to Peer Streaming Protocol Definition (PPSP) and Scope...4 63 4. Comparison with related protocols............................6 64 4.1. P2PSIP.................................................6 65 4.2. RTSP and related protocols..............................8 66 5. Scenarios of Inter-working of PPSP...........................8 67 5.1. Non CDN assistant inter-worked PPSP.....................8 68 5.2. CDN assistant inter-worked PPSP.........................9 69 6. Security Considerations......................................9 70 7. Acknowledgments............................................10 71 8. References.................................................11 72 Author's Addresses............................................11 74 1. Introduction 76 Nowadays Peer to Peer computing has been successfully used in many 77 fields, from one to one communication like VoIP, IM to one to many 78 communication like streaming, file sharing and gaming. In streaming 79 area, with the popularity of P2P technology, PPlive[1], PPstream[2], 80 UUSee[3] ,Pando[4] etc. show the prosperity of P2P real time and VOD 81 streaming applications. Take pplive for example, it has over 5 82 million online users at the same time for real-time streaming. Also 83 some web2.0 streaming applications such as youtube[5], tudou [6]are 84 reported to use or prepare to use P2P engine to accelerate its 85 downloading rate and cut down the transmission cost esp in the winter 86 of finance crisis which is being widespread all over the world. 88 Basically there are two kinds of streaming solutions: client-server 89 streaming and P2P streaming. Some client-server streaming control 90 protocols have been developed both within and out of IETF, including 91 RTSP[7], MMS[8],PNA[9] and HTTP. As for p2p streaming applications, 92 there already exist a lot of real time and VOD applications like 93 PPlive, PPStream, UUSee in China and Pando in the USA, each of which 94 uses its proprietary protocol. P2P streaming applications account for 95 more and more Internet traffic. According to statistics in a main 96 china ISP, PPlive accounts 10% of the total Internet backbone traffic. 97 In contrast, Bittorrent's traffic share is about 8% in the ISP's 98 backbone. 100 Therefore there is no doubt that P2P streaming is more and more 101 important in the Internet. It's time to draw up an open P2P streaming 102 protocol in IETF to make P2P streaming wider adoption and regulate 103 its behavior from the whole Internet point of view. 105 2. Problem Statement of P2P streaming Applications 107 Although P2P streaming applications are popular in the Internet, 108 there are still some unsolved problems surrounding them: 110 First, the startup delay(20~30s), the latency between the 111 broadcasting time and the audience view time(120s), the re-buffering 112 time after a dragging or forward/backward in VoD(6~8s) and the 113 channel switch time are still long. How to reduce these delays in the 114 Internet is an open question for researchers; 116 Second, the video quality is still very low for p2p streaming 117 applications, most of which has a playback rate of some hundreds kbps. 118 These may be attributed to several factors, e.g., current low access 119 bandwidth and asymmetrical upload and download bandwidth like ADSL 120 and cable modem, How to improve the video quality under such network 121 environment is an open problem. Even suppose when there is a higher 122 access bandwidth like LTE which has over 100Mbps bandwidth, it is 123 still a question if current P2P streaming mechanisms work to support 124 high quality streaming because of different wireless network 125 environment. 127 Third, the dragging and backward/forward performance in VoD is 128 unacceptable in current p2p streaming applications. The lack of 129 upload bandwidth where ADSL and cable modem dominating the access 130 network indicates a peer-assistant method like CDN can make the 131 dragging performance better. How to change current CDN to accommodate 132 p2p streaming environment and integrate them together is an open 133 question. 135 Fourth, traffic localization and transport protocol optimization are 136 very important problems in p2p streaming environment being discussed 137 in ALTO and TANA in IETF. So PPSP can reuse the fruits of ALTO and 138 TANA. 140 Last but not least, from the protocol perspective, private protocol 141 has the following problems: for end users, he needs multiple client 142 software to view different programs; for operators, it's difficult to 143 identify these different applications and for service provider, it 144 has to pay much attention to both programs source and P2P delivery 145 technology. So an open peer to peer streaming protocol is required to 146 meet the requirements mentioned above. 148 3. Peer to Peer Streaming Protocol Definition (PPSP) and Scope 150 The basic mission of PPSP is to create a distributed real-time data 151 retrieval protocol in one to many communication (or data-driven 152 communication).One to many communication is different from one to one 153 communication where there is known destination to visit. In one to 154 many communication, the destinations are unknown and the concrete 155 data are stored piece by piece in different peers and the key is to 156 find those data and reassemble them. 158 Therefore, PPSP focuses on how to negotiate with un-preassigned peers 159 for needed chunks along with some application requirements parameters 160 and transmit the retrieved content accordingly. PPSP involves a 161 bundle of interactions, including interaction between peers, between 162 peers and trackers, between peer and CDN. Note that CDN can be viewed 163 as a special peer who has a complete copy of the programs in VoD and 164 a super-stable peer with higher upload and download bandwidth in 165 real-time streaming. From the protocol type perspective, PPSP 166 includes streaming control (Step 1-4 and 7) and transmission protocol 167 (Step5) which will be discussed in the following part The protocol 168 stack of PPSP is shown in Fig1. 170 +------------------------+ 171 | PPSP Application | 172 +------------------------+ 173 | PPSP Signaling Protocol| 174 +------------------------+ 175 | PPSP Trans Protocol | 176 +------------------------+ 177 | Transport Layer | 178 +------------------------+ 180 Figure 1 PPSP Position in Protocol Stack. 182 The process of PPSP applications is shown in Fig2. We explain it 183 as follows: 185 1. Peer sending PPSP signaling request with parameters(e.g., QoS, 186 location, historical records such as online duration) 187 2. Tracker returning Peer list according to the parameters through 188 PPSP signaling protocol. 189 3. Peer Gossiping communication among peer candidates to exchange 190 chunk bitmap and find a chunk through PPSP signaling protocol. 191 4. Peer Scheduling where to get the chunk and do cache replacement 192 e.g., BT like, rarest first .This action is done by peer itself 193 and doesn't include interaction with other peers or network. So 194 it's beyond the scope of PPSP. 195 5. Chunk transmission among peers (including CDN transmission) through 196 PPSP transmission protocol: There are two levels of work in this 197 step. One level is to deploy TCP/UDP/RTP as the basic transmission 198 protocol. Generally UDP is used in practice to reduce the 199 transmission overhead. An open question exists that if RTP can be 200 used here. The other level is what kind of rules the peers take in 201 transmission. These rules are as important as the basic 202 transmission protocols in one to many communication, because the 203 basic task there is to get the data from different source as soon 204 as possible or distribute its data with the lowest cost in a scale. 205 It makes p2p streaming transmission different from pure TCP/UDP/RTP 206 level work. The rules vary much according to different requirements. 207 For instance, a peer can transmit a chunk by maximizing download 208 rate or minimizing transmission overhead according the network 209 conditions. These rule leads to different peer's actions, e.g., a 210 peer can send a request for the same content to multiple neighbors 211 simultaneously, to ensure it gets the content in time; or request 212 for different content from multiple neighbors simultaneously; when 213 a request times out, it is redirected to a different neighbor; or 214 work with one neighbor at a time; only when that neighbor times out, 215 try to connect to a different neighbor. Obviously it creates many 216 critical parameters in transmission, e.g., response time, the 217 number of simultaneous neighbors to send requests. To tune these 218 parameters network monitoring is required to regulate in the 219 protocols. 220 6. Peer Re-assembling the chunk in its cache to finish playback of the 221 programs. 222 7. Peer Reporting to Tracker what chunks it has periodically. This is 223 publishing process where PPSP signaling protocol can be used. 225 +---------+ 226 | Tracker | 227 +---------+ 228 ^ | 229 | | +----------+ 230 1,7| | 2 | Peer 4 | 231 | | +----------+ 232 | V 233 +---------+ +----------+ 234 4,6| Peer 1 |<----3---->| Peer 2 | 235 +---------+<----5---- +----------+ 236 ^ ^ 237 5| |3 238 | | 239 | V 240 +---------+ 241 | Peer 3 | 242 +---------+ 244 Figure 2 PPSP Process 246 4. Comparison with related protocols 248 4.1. P2PSIP 250 P2PSIP deals with resource location in one to one commutation. The 251 iterative and recursive routing process inP2PSIP is shown in Fig3, 252 which is different from PPSP. That is, the data stored in P2P SIP is 253 user profile data and user knows exactly what the data is (e.g., the 254 location of Alice@chinamobile.com) using RELOAD to locates the data. 255 While in PPSP scenarios, there are many peers storing data pieces of 256 "Mr. and Ms. Smith" and the user doesn't know and needn't know the 257 belongings of the peers and he just know the metadata of the movie. 258 He must use a gossip protocol to communicate with other peers to get 259 the real data quickly. 261 +------------------+ 262 | Peer | 263 +------------------+ 264 ^ | ^ | 265 | | | | 266 1,2 | | 1' 3,4| |3' 267 | | | | 268 V V V V 269 +-----------+ +-----------+ 270 | Peer |--2'->| Peer | 271 +-----------+ +-----------+ 273 Fig3 P2PSIP process 275 The difference between P2PSIP and PPSP are as follows: 277 1) One to one communication VS One to many communication (End to End 278 communication VS data centric communication): 279 a) Because there are lot of peer candidates in PPSP, NAT 280 transversal is not as important as that in P2PSIP and public peers 281 can be found with higher probability; 282 2) PPSP includes transmission Protocol and P2PSIP doesn't involve that. 283 3) Different Search efficiency requirement: 284 a) PPSP requires retrieval real-time/para real-time data, iterative 285 and recursive routing is not suitable for low efficiency. 286 b) Node organizations are quite different. DHT doesn't fit for 287 peers in PPSP. 288 4) Different transmission quality requirements: P2PSIP doesn't require 289 Voice quality and PPSP need to ensure streaming quality. Therefore 290 in PPSP the following factors in peers must be considered: 291 a) Heterogeneous nodes; 292 b) Node Churn and Data Churn(the data update quicker than P2PSIP) 293 c) Topology-aware 294 5) Different applicable services: P2PSIP is suitable for VoIP and 295 PPSP is suitable for streaming, gaming and file sharing. It's too 296 comprehensive for P2PSIP (based on text) for non-session applications 297 like streaming. There are too many signaling interactions with much 298 overhead compared with P2PSIP which has only one interaction. 300 Although P2PSIP doesn't fit for peer organization, it can be deployed 301 in PPSP environment to some extent. DHT can be used to organize 302 multiple channel servers in real-time streaming or multiple file 303 trackers in VoD. Because the search time of which channel or which 304 file the tracker stores accounts little in the whole searching 305 procedure, DHT can be used to query for peer list in case of thousand 306 of channels or million of files which are hard to use one tracker. 307 But it doesn't fit for quick search for real data among peers yet. 309 4.2. RTSP and related protocols 311 At first sight, the function of PPSP control protocol is similar to 312 traditional C/S style streaming control protocols RTSP, MMS or PNA. 313 But in fact RTSP MMS or PNA don't involve the problems PPSP has 314 because the end user requests the streaming from one assigned source 315 without needing real-time resource discoery, merge and 316 synchronization, which simplifies the problem. However it also 317 inherits the shortcomings of all client-server paradigms including 318 low scalability, high cost both for investment and maintenance as 319 well as the traffic pressure for the Internet equipments and single 320 point of failure. 322 5. Scenarios of Inter-working of PPSP 324 PPSP can be used not only within a single p2p application, but also 325 in the inter-working of different p2p applications. 327 5.1. Non CDN assistant inter-worked PPSP 329 In this case PPSP can be used by different P2P streaming applications 330 which can share resources and improve performance with better peers 331 from allied P2P streaming applications. P2P streaming applications 332 don't deploy CDN for streaming delivery. The interaction between 333 different PPSP applications is shown in Fig4. It involves steps 334 beyond basic PPSP process, e.g., trackers from different vendors 335 exchange their peer information. 337 +----------------------------+ 338 | PPSP APP 1 | PPSP App 2 | 339 +----------------------------+ 340 | ^ ^ | 341 | | | | 342 | +---------------+ | 343 | PPSP Signaling Protocol | 344 +----------------------------+ 345 | PPSP Trans Protocol | 346 +----------------------------+ 347 | Transport Layer | 348 +----------------------------+ 350 Fig4 Interaction between different P2P applications 352 5.2. CDN assistant inter-worked PPSP 354 In this case there is usually a CDN provider that may be run by an 355 ISP. It provides P2P streaming distribution services for different 356 PPSP applications. The storage and transmission bandwidth can be 357 saved in case of the same content transmission for different PPSP 358 applications. The cooperation between different PPSP providers can be 359 run both in PPSP transport level and PPSP signaling level as shown in 360 Fig5. 361 +----------------------------+ 362 | PPSP APP 1 | PPSP App 2 | 363 +----------------------------+ 364 | ^ ^ | 365 | | | | 366 | +---------------+ | 367 | PPSP| Signaling Prot|ocol | 368 +----------------------------+ 369 | +---------------+ | 370 | PPSP Trans Protocol | 371 +----------------------------+ 372 | Transport Layer | 373 +----------------------------+ 375 Fig5 Interaction between different P2P applications 377 6. Security Considerations 379 PPSP doesn't relate to security mechanisms currently, but we don't 380 exclude security mechanisms in PPSP. 382 7. Acknowledgments 384 We have to acknowledge many people. For the record: N.Zong, X.F.Jiang, 385 H.B.Song. Pick.Li from Huawei. 387 References 389 [1] www.pplive.com 391 [2] www.ppstream.com 393 [3] www.uusee.com 395 [4] www.pando.com 397 [5] www.youtube.com 399 [6] www.tudou.com 401 [7] www.ietf.org/rfc/rfc2326.tx 403 [8] en.wikipedia.org/wiki/Microsoft_Media_Services 405 [9] all-streaming-media.com/streaming-media-faq/faq-pnm- 406 protocol.htm 408 Author's Addresses 410 Yunfei Zhang 411 China Mobile 413 Phone: 86 13601032119 414 Email: zhangyunfei@chinamobile.com