idnits 2.17.1 draft-zhang-ppsp-problem-statement-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 17) being 77 lines 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.) ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2009) is 5520 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: '00101' is mentioned on line 171, but not defined ** Obsolete normative reference: RFC 2326 (ref. '7') (Obsoleted by RFC 7826) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPSP Y.Zhang 2 Internet Draft China Mobile 3 Intended status: Standards Track N.Zong 4 Expires: September 2009 Huawei Tech. 5 J.Seng 6 PPlive 7 H.Zhang 8 NEC Lab,USA 9 March 9, 2009 11 Problem Statement of P2P Streaming Protocol (PPSP) 12 draft-zhang-ppsp-problem-statement-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on September 9, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 This draft proposes to develop an open p2p streaming protocol, namely 51 PPSP. We survey the current practice of p2p streaming applications, 52 analyze the incentive to develop PPSP and its applying scenarios. 53 Then we introduce the PPSP interaction process and state the problem 54 of PPSP and its scope. In the last section we also analyze the 55 relationship between PPSP and P2PSIP as well as RTSP. 57 Table of Contents 59 1. Overview.....................................................4 60 2. Incentive of an open P2P streaming Protocol..................5 61 3. Peer to Peer Streaming Protocol(PPSP) Interactions..........10 62 4. Problem Statement and Scope of PPSP.........................12 63 5. Comparison with related protocols...........................14 64 5.1. P2PSIP.................................................14 65 5.2. RTSP and related protocols.............................15 66 6. Security Considerations.....................................16 67 7. Acknowledgments.............................................16 68 8. References..................................................16 69 8.1. Normative References...................................16 70 8.2. Informative References.................................17 72 1. Overview 74 Peer to Peer video streaming applications have been successfully 75 dominating Internet traffic in recent times. According to statistics 76 in a main china ISP in 2008, PPLive accounts 10% of the total 77 Internet backbone traffic. In contrast, Bittorrent, one of the most 78 popular p2p file downloading software, contributes to less than 8% of 79 the backbone traffic. 81 Some big vendors, PPLive[1], PPstream[2], UUSee[3] and Pando[4] etc. 82 show the popularity of P2P streaming applications. Take PPLive for 83 example, it has over 2 million online users at the same time to watch 84 live programs such as CCTV spring festival gala. 86 P2P video streaming technology has become an important part of the 87 Internet. 89 2. Incentive of an open P2P streaming Protocol 91 Basically there are two architectures for video streaming: client- 92 server streaming paradigm and P2P streaming paradigm. Client-server 93 streaming paradigm has been well studied which can be depicted by the 94 following figure 1. 96 +----------------------------------+ 97 | Streaming Application | 98 |----------------------------------| 99 | RTSP/MMS/PNA/HTTP | 100 |-----------------+----------------| 101 | RTP | RTCP | 102 |-----------------+----------------| 103 | UDP/TCP | 104 |----------------------------------| 105 | IP Protocol | 106 +----------------------------------+ 108 Figure 1 Client/server Streaming Stack 110 Basically client-server streaming comprises of two parts of protocols: 111 transport protocol and signaling protocol. Transport protocol is used 112 for viedo payload transmission between the client and the server. 113 Signaling protocol is used to negotiate streaming controls between 114 the client and the server. RTP and RTCP,are designed for streaming 115 transmission.RTSP[7], MMS[8],PNA[9] and HTTP are used as streaming 116 signaling protocols. However its scalability, reliability and 117 availability faces with serious problems with a large number of 118 audience simultaneously viewing the programs. 120 P2P technology provides a good candidate for streaming applications 121 to solve such problems. It partitions streaming source into pieces 122 which are distributed over peers when the audience views the programs. 123 Therefore peers need to locate and receive the stream chunks from 124 multiple sources simultaneously, which eliminates single point of 125 failure. The biggest problem is therefore how to make sure real-time 126 data retrieval and transmission that can keep up with the source 127 broadcasting. To the best of our understanding, current p2p streaming 128 protocols have common underlying design principles. According to our 129 measurement work[11], existing p2p streaming systems like pplive, 130 ppstream and uusee deploy a similar architecture and signaling 131 transaction process. Therefore it's possible to develop an open p2p 132 streaming protocol to integrate existing p2p streaming protocols. 134 However, almost all of the existing p2p streaming software use their 135 proprietary protocols, esp. in the signaling part. Proprietary 136 protocols protect the service providers from easily copied. These 137 protocols are not interoperability with each another and pose a 138 barrier of entry for other p2p streaming providers. On the other 139 hand,it also increases the cost for outsiders to improve such systems 140 or develop a new p2p streaming system or video accelerator system 141 (transition from traditional cache or CDN)from scratch without an 142 open p2p streaming protocol. Moreover, this makes it hard for anyone 143 outside a P2P streaming service to interact with it including 145 1) ISPs for traffic management and optimization; 147 2) Other streaming services for content/user sharing; 149 3) Hardware vendors for set-top box or mobile terminals supporting 150 p2p streaming 152 and vice versa. The only means to learn such systems is Internet 153 measurement. People can know how a p2p streaming system works by 154 analyzing such p2p streaming systems by either active or passive 155 measurement. Unfortunately some of p2p streaming systems have been 156 encrypted or scrambled due to content pollution protection. Once the 157 system is encrypted, the last means is of no use. 159 What's more, an open p2p streaming protocol has more benefit under 160 the following scenarios. 162 1) Better Performance with inter-worked p2p streaming systems: 163 According to the measurement study of comparison on pplive and 164 ppstream protocols [11], their peer lists don't overlap and can be 165 complementary to each other at a certain time. In PPlive the chunk 166 fetch policy is both sequential fetching and rarest first at same 167 time while in ppstream the chunk fetch is random selection in each 168 buffer window. We can see it clearly in figure2. Suppose pplive and 169 ppstream are transmitting the same programs piece#1, in a certain 170 time round1,peer1 in ppstream may fetch chunk#3 and #5 and update its 171 bitmap with [00101] according to random chunk selection. If peer2 172 is the new comer to request program piece#1 in ppstream, he asks the 173 tracker to get peer1 information. However peer1 doesn't contain 174 chunk#1 and chunk#2 information. So peer2 has to wait for other peers 175 holding chunk#1 and chunk#2, which causes more latency before viewing 176 the program. If there is an open p2p streaming protocol, pplive and 177 ppstream can inter-work and exchange peer information, things are 178 quite different. In time round1,peer3 in pplive may fetch chunk#1 and 179 chunk#2 according to its chunck fetch policy. If this information can 180 be used by ppstream users, peer2 may fetch chunk#1 and #2 from peer3 181 to save the caching time. 183 +----------------------------------+ 184 | <--- Program Piece#1---> | 185 | | 186 | +----+----+----+----+----+----+ | 187 | | | | | | | | | 188 | | 1 | 2 | 3 | 4 | 5 | 6 | | 189 | | | | | | | | | 190 | +----+----+----+----+----+----+ | 191 +----------------------------------+ 193 Figure 2 Program Piece Partition and Chunk Fetch 195 2) Wider coverage of streaming services: There is usually serious 196 competition among P2P streaming providers for similar program source 197 in the same country while P2P streaming providers in different 198 countries may cooperate to share program information to broaden its 199 audience. An open p2p streaming protocol helps different P2P 200 streaming providers to share both programs and user resources. 202 3) Integration of current caches, CDNs and video-sharing websites by 203 a uniform p2p streaming protocol. There are lots of web caches and 204 CDNs in current Internet. However most of them don't support 205 streaming services, let alone p2p streaming. In the winter of finance 206 crisis which is being widespread all over the world, p2p streaming 207 technologies are regarded a good tool to accelerate the download rate 208 and reduce the transmission cost for the video websites like 209 youtube[5]and tudou [6]. Some traditional CDNs are trying to add p2p 210 mechanisms to support video acceleration[10].If a uniform p2p 211 streaming protocol is developed, traditional caches and CDN nodes can 212 easily deploy p2p technology based on current platform. This will be 213 a great save in transmission cost. 215 4) Providing mobile and wireless streaming: Mobility becomes a very 216 important feather to support in future internet. Many next generation 217 Internet studies investigate to introduce distributed mobile services 218 like GENI[12] and FIND[13]. Many operators have also been launching 219 research projects on mobile Internet practice. For example, China 220 Mobile came out with its DSN (distributed services network)strategy 221 last year as the core network of its mobile Internet. Readers can 222 refer to draft-zhang-ppsp-dsn-introduction[14] for more details. 224 However there are some differences in mobile Internet compared to 225 fixed Internet environment. This makes it hard to copy current p2p 226 streaming protocol in mobile and wireless environment. 228 a) End to end communication is harder. Unlike fixed Internet, it's 229 difficult to realize end-to-end communication in mobile Internet. 230 For example, currently mobile phone cannot connect with each other 231 directly. The connection must be set up by wireless access nodes 232 like GGSN. Therefore mobile phone is hard to become a peer in p2p 233 streaming environment without the cooperation of mobile access 234 equipments. 236 b) Limited Bandwidth resource. Every mobile node has a small 237 bandwidth and the transmission cost is relatively high. To make 238 p2p streaming applications available in mobile internet, some 239 mechanisms to reduce bandwidth consumption is necessary such as 240 broadcasting. A practical means may be to distribute streaming 241 data to mobile access nodes using the-state-of-art p2p streaming 242 technologies and the mobile access nodes may broadcast the stream 243 data to end users. 245 The above two problems call for redefining an open p2p streaming 246 protocol by both operators and service providers. 248 c) Worldwide service provision is harder. For instance, suppose China 249 Mobile launches streaming services cooperated with pplive, the 250 users cannot use it in USA if Verizon cooperates with Pando for 251 streaming services. Although the user can connect with pplive 252 tracker, there is no Verizon users listed in the returned peerlist. 253 The mobile access nodes in Verizon may block multiple incoming 254 streams to the user who is not Verizon's streaming subscribers. An 255 open p2p streaming protocol helps China mobile and Verizon to 256 cooperate in caching the data stream or exchanging local peer 257 information. 259 d) Converged service provision needs to repair current protocols. 260 There are two converged scenarios. 262 First, suppose a hybrid mobile/wireless and wired Internet 263 environment, it's possible for wired users (who may have multiple 264 interfaces including wireless interface) and wireless users to 265 cooperate with each other. Different from current p2p streaming 266 protocol, user information such as online time, link condition, node 267 capability or battery information and other useful information must 268 be provided for trackers. Peers may even switch from a strong peer 269 (contributing to others) with WLAN connections and high battery 270 volume to a weak peer(contributing nothing) with CDMA connections and 271 low battery volume. We foresee that peer-to-peer video streaming 272 protocol should take these into account to more efficiently use the 273 available peer information. 275 If we repair the current proprietary protocols, there are lot of 276 repeated works to do for different streaming vendors. An open p2p 277 streaming protocol seems a better choice. 279 Second, seamless switch between mobile and fixed nodes needs to 280 repair the current protocol. In future internet, users can easily 281 watch p2p streaming with their mobile phones in the way home and once 282 they arrive home, the program can be seamlessly switched to display 283 in TV set. However current p2p streaming protocol doesn't support 284 this without explicit user location information appeared in the 285 tracker. 287 5) End users need only one p2p streaming client to support multiple 288 p2p streaming vendors with an open p2p streaming protocol. This is 289 especially useful for resource-constraint end users devices such as 290 mobile phones or PDAs. 292 To sum up, an open p2p streaming protocol is necessary in future 293 Internet to benefit for each side, including service providers, ISPs, 294 network and terminal equipment vendors, researchers as well as end 295 users. It allows for involving more participants in p2p streaming 296 with better performance and more audience. 298 We'd like to point out that an open protocol won't weaken the 299 independence of current p2p streaming providers. It depends on the 300 vendors' strategy. If they wish to cooperate with each other, it's 301 easy to inter-work; or else it can be easily protected by data 302 encryption or other DRM means. 304 3. Peer to Peer Streaming Protocol(PPSP) Interactions 306 Peer to Peer Streaming Protocol(PPSP) involves a bundle of 307 interactions. From the measurement research we have done in the 308 draft[11], there are two roles in current tracker-based p2p streaming 309 structure: peer and tracker. PPSP includes interaction between peers, 310 between peers and trackers. In some practice, CDN nodes are added in 311 p2p streaming structure. Note that CDN can be viewed as a special 312 peer who has a complete copy of the programs in VoD and a super- 313 stable peer with higher upload and download bandwidth in real-time 314 streaming. 316 We conclude the process of PPSP applications as follows. 318 1) Peer sending request with parameters(e.g., QoS, location, 319 historical records such as online duration). 321 2) Tracker returning Peer list according to the parameters. 323 3) Peer gossiping communication among peer candidates to exchange 324 chunk bitmap and find a chunk. 326 4) Peer scheduling where to get the chunk and do cache replacement 327 e.g., BT like, rarest first . This action is done by peer itself 328 and doesn't include interaction with other peers or network. 330 5) Chunk transmission among peers(including CDN transmission): 332 6) Peer Re-assembling the chunk in its cache to finish playback of 333 the programs. 335 7) Peer reporting to Tracker what chunks it has periodically. 337 +------------------------------------------------+ 338 | +---------------+ | 339 | | Tracker | | 340 | +---------------+ | 341 | ^| | 342 | ||2 +------------+ | 343 | || | Peer 4 | | 344 | 1,7|V +------------+ | 345 | +-------------+ 3 +------------+ | 346 | 4,6| Peer1 |<--->| Peer 2 | | 347 | +-------------+<--->+------------+ | 348 | ^ 5 | 349 | 3| | 350 | V | 351 | +------------+ | 352 | | Peer 4 | | 353 | +------------+ | 354 +------------------------------------------------+ 356 Figure 3 PPSP Interactions 358 4. Problem Statement and Scope of PPSP 360 We propose to develop an open peer to peer streaming protocol, namely 361 PPSP. The basic problem of PPSP is to define a protocol of locating 362 and transmitting real-time and VoD data efficiently from multiple 363 sources with different pieces in peer to peer environment. This is an 364 one to many communication (or data-driven communication).One to many 365 communication is different from one to one communication where there 366 is known destination to visit. In one to many communications, the 367 destinations are unknown and the concrete data are stored piece by 368 piece in different peers and the key is to find those data and 369 reassemble them. 371 PPSP focuses on how to negotiate with un-preassigned peers for needed 372 chunks and transmit the retrieved content accordingly. Therefore, 373 PPSP can be divided into PPSP signaling protocol and transmission 374 protocol. The protocol stack of PPSP is shown in Fig4. Based on our 375 previous work, we leave the transport protocol in the second stage. 376 For the purpose of this document, we focus only on PPSP signaling 377 protocol for real-time streaming. 379 +------------------------------+ 380 | PPSP Application | 381 |------------------------------| 382 | PPSP Signaling Protocol | 383 |------------------------------| 384 | PPSP Trans Protocol | 385 |------------------------------| 386 | Transport Layer | 387 +------------------------------+ 389 Figure 4 PPSP Position in Protocol Stack 391 In the signaling part, in order to locate real-time data efficiently 392 from multiple sources with different pieces, we have to solve the 393 following problems: 395 1) To standardize the architecture for locating the data efficiently. 397 Tracker-based structure is widely used in current p2p streaming 398 practice. However some tracker-less structures like DHT peer 399 management solutions are also proposed. We need to decide which one 400 is better for p2p streaming; 402 2) To standardize the signaling interaction process. 404 In this part we actually want to standardize client registration 405 process (analogous to TCP 3-way handshake procedure), client 406 information exchange process (analogous to SIP session setup process) 407 and client report process. 409 The current tracker-based means is a two-step searching, i.e., peer 410 reporting to tracker coarse information about it has. Once the 411 tracker is asked, it informs peer of the coarse information; the 412 grain information is achieved by peers exchanging bitmap each other. 413 Some other means, e.g., peer reporting to tracker grain information 414 directly and tracker informs peer of the exact information or DHT 415 based searching, should be evaluated. In each proposal we also need 416 to define the message format in the interactions. 418 2) To discuss how to incorporate node information such as online time, 419 link status, node capability, battery information and some 420 application requirements parameters into the protocol to expand the 421 peer selection. 423 In this part, we actually want to standardize PPSP message headers 424 (analogous to IP header definition) and PPSP metadata format 425 (analogous to SIP header definition). 427 In the future, after we finish developing PPSP signaling protocol, 428 PPSP transport protocol may also be standardized for client data 429 transfer process,e.g., one-to-many transport protocol based on UDP, 430 TCP and RTP. This is beyond current TCP, UDP or RTP scope. 432 5. Comparison with related protocols 434 5.1. P2PSIP 436 P2PSIP deals with resource location in one to one commutation. The 437 iterative and recursive routing process inP2PSIP is shown in Fig5, 438 which is different from PPSP. That is, the data stored in P2P SIP is 439 user profile data and user knows exactly what the data is (e.g., the 440 location of Alice@chinamobile.com) using RELOAD to locates the data. 441 While in PPSP scenarios, there are many peers storing data pieces of 442 ''Mr. and Mrs. Smith'' and the user doesn't know and needn't know the 443 belongings of the peers and he just know the metadata of the movie. 444 He must use a gossip protocol to communicate with other peers to get 445 the real data quickly. 447 +------------------------------------------------+ 448 | +---------------+ | 449 | | Peer | | 450 | +---------------+ | 451 | ^ | ^ | | 452 | 1,2 | |1' 3,4| |3' | 453 | | | | | | 454 | V V V V | 455 | +-------------+ 2' +------------+ | 456 | | Peer |----->| Peer | | 457 | +-------------+ +------------+ | 458 | | 459 +------------------------------------------------+ 461 Figure 5 P2PSIP process 463 The difference between P2PSIP and PPSP are as follows: 465 1) One to one communication VS one to many communication (End to End 466 communication VS data centric communication).Because there are lot of 467 peer candidates in PPSP, NAT transversal is not as important as that 468 in P2PSIP and public peers can be found with higher probability; 470 2) PPSP includes transmission Protocol and P2PSIP doesn't involve 471 that. 473 3) Different Search efficiency requirements. PPSP requires retrieval 474 real-time/para real-time data, iterative and recursive routing is not 475 suitable for low efficiency. 477 4) Different transmission quality requirements: In PPSP some extra 478 factors in peers must be considered, e.g.,heterogeneous nodes,node 479 churn and data churn(the data update quicker than P2PSIP)and 480 topology-aware; 482 5) Different applicable services: P2PSIP is suitable for VoIP and 483 PPSP is suitable for streaming, gaming and file sharing. 485 Although P2PSIP doesn't fit for streaming peer organization, it can 486 be deployed in PPSP environment to some extent. DHT can be used to 487 organize multiple channel servers in real-time streaming or multiple 488 file trackers in VoD. Because the search time of which channel or 489 which file the tracker stores accounts little in the whole searching 490 procedure, DHT can be used to query for peer list in case of thousand 491 of channels or million of files which are hard to use one tracker. 492 But it doesn't fit for quick search for real data among peers yet. 494 5.2. RTSP and related protocols 496 At first sight, the function of PPSP control protocol is similar to 497 traditional C/S style streaming control protocols RTSP, MMS or PNA. 498 But in fact RTSP MMS or PNA don't involve the problems PPSP has 499 because the end user requests the streaming from one assigned source 500 without needing real-time resource discovery, merge and 501 synchronization, which simplifies the problem. However it also 502 inherits the shortcomings of all client-server paradigms including 503 low scalability, high cost both for investment and maintenance as 504 well as the traffic pressure for the Internet equipments and single 505 point of failure. 507 6. Security Considerations 509 PPSP include security mechanisms. Now we are at the beginning stage 510 and security issues need to be further investigated. 512 7. Acknowledgments 514 We have to acknowledge many people. For the record: C.Williams and 515 J.Wang from ZTE X.Jiang, H.Song. P.Li from Huawei,X.Zhang from 516 PPlive,S.Shen and L.Xiao from NSN H.Deng from China Mobile and J.Lei 517 from Univ.Goettingen. 519 8. References 521 8.1. Normative References 523 [7] www.ietf.org/rfc/rfc2326.txt 525 [8] en.wikipedia.org/wiki/Microsoft_Media_Services 527 [9] all-streaming-media.com/streaming-media-faq/faq-pnm- 528 protocol.htm 530 8.2. Informative References 531 [1] www.pplive.com 533 [2] www.ppstream.com 535 [3] www.uusee.com 537 [4] www.pando.com 539 [5] www.youtube.com 541 [6] www.tudou.com 543 [10] www.chinacache.com 545 [11] www.ietf.org/internet-drafts/draft-zhang-ppsp-protocol- 546 comparison-measurement-00.txt 548 [12] www.geni.net 550 [13] www.nets-find.net 552 [14] www.ietf.org/internet-draft/draft-zhang-ppsp-dsn-introduction- 553 00.txt 555 Author's Addresses 557 Yunfei Zhang 558 China Mobile 560 Phone: 86 13601032119 561 Email: zhangyunfei@chinamobile.com 563 Ning Zong 564 Huawei Tech. 566 Email: zongning@huawei.com 568 James Seng 569 PPlive 571 Email: james.seng@pplive.com 573 Hui Zhang 574 NEC Lab,USA 576 Email: huizhang@nec-labs.com