idnits 2.17.1 draft-zhang-ppsp-problem-statement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 543 has weird spacing: '...tisment polic...' -- The document date (July 12, 2009) is 5400 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: 'P2PStreamingSurvey' is mentioned on line 88, but not defined == Missing Reference: 'PPstream' is mentioned on line 101, but not defined == Missing Reference: 'P2PStreamSurvey' is mentioned on line 121, but not defined == Missing Reference: 'Pando' is mentioned on line 182, but not defined == Missing Reference: 'Coolstreaming' is mentioned on line 183, but not defined == Missing Reference: 'HTPT' is mentioned on line 473, but not defined == Missing Reference: 'FIND' is mentioned on line 224, but not defined == Missing Reference: 'Survey' is mentioned on line 321, but not defined == Unused Reference: 'PPStream' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'Octoshape' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'CoolStreaming' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'HPTP' is defined on line 682, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Cisco' -- Possible downref: Non-RFC (?) normative reference: ref. 'PPLive' -- Possible downref: Non-RFC (?) normative reference: ref. 'PPStream' -- Possible downref: Non-RFC (?) normative reference: ref. 'UUSee' -- Possible downref: Non-RFC (?) normative reference: ref. 'CNN' -- Possible downref: Non-RFC (?) normative reference: ref. 'Octoshape' -- Possible downref: Non-RFC (?) normative reference: ref. 'CoolStreaming' == Outdated reference: A later version (-02) exists of draft-zhang-ppsp-protocol-comparison-measurement-00 ** Downref: Normative reference to an Informational draft: draft-zhang-ppsp-protocol-comparison-measurement (ref. 'HPTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'GENI' -- Possible downref: Non-RFC (?) normative reference: ref. 'MobileTV' Summary: 5 errors (**), 0 flaws (~~), 15 warnings (==), 10 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: Standard track N.Zong 4 HuaweiTech 5 G.Camarillo 6 Ericsson 7 J.seng 8 PPlive 9 R.Yang 10 Yale University 11 Expires: January 2010 July 12, 2009 13 Problem Statement of P2P Streaming Protocol (PPSP) 14 draft-zhang-ppsp-problem-statement-04.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on January 12, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your 46 rights and restrictions with respect to this document. 48 Abstract 49 We propose to develop an open peer-to-peer (P2P) streaming protocol 50 named PPSP. This document describes problems related to PPSP and 51 outlines considerations that have to be taken in account when 52 arriving at equitable solutions. 54 Table of Contents 56 1. Introduction.............................................4 57 1.1. Research or Engineering.............................4 58 1.2. Objective and outline...............................5 59 2. Definitions..............................................6 60 3. Problem Statement Scope..................................7 61 3.1. Proprietary protocols and an open PPSP..............7 62 3.2. Integrating cache and CDN into P2P streaming........7 63 3.3. Integrating existing protocols into P2P streaming...8 64 3.4. Mobility and wireless issue.........................8 65 3.4.1. End to end communication is harder..............9 66 3.4.2. Limited Bandwidth resource......................9 67 3.4.3. Other difference...............................10 68 4. Design Issues...........................................11 69 4.1. Architecture Choice................................11 70 4.2. Integration with existing protocols................11 71 4.2.1. Integration with RELOAD........................11 72 4.2.2. Integration with ALTO..........................14 73 4.2.3. Encapsulating RTSP.............................14 74 4.2.4. Edge Device such as Cache Integration..........15 75 5. Scope of Work...........................................16 76 5.1. Architecture of PPSP...............................16 77 5.2. Scope of PPSP......................................18 78 6. Security Considerations.................................21 79 7. Acknowledgments.........................................21 80 8. References..............................................21 82 1. Introduction 83 Streaming traffic is among the fastest growing traffic on the 84 Internet. In a recent white paper, Cisco predicts that by 2012, 90% 85 of all Internet traffic will be video [Cisco]. 86 There are two basic architectures for delivering streaming traffic on 87 the global Internet: the client-server paradigm and the peer to peer 88 (P2P) paradigm [P2PStreamingSurvey]. A particular advantage of the 89 P2P paradigm over the client-server paradigm is its scalability. As 90 an example, PPLive [PPLive], one of the largest P2P streaming vendors, 91 is able to distribute large-scale, live streaming programs such as 92 the CCTV Spring Festival Gala to more than 2 million users with only 93 a handful of servers. CNN[CNN] reported that P2P streaming by 94 Octoshape played a major role in its distribution of the historical 95 inauguration address of President Obama. It is well demonstrated in 96 practice that P2P streaming can deliver videos encoded at a rate of 97 about 400 Kbps, in the presence of rapid user joins/leaves, with 98 positive user experiences. 99 With the preceding technical advantages, P2P streaming is seeing 100 rapid deployment. Large P2P streaming applications such as PPLive 101 [PPLive], PPstream [PPstream] and UUSee [UUSee] each has a user base 102 exceeding 100 millions. P2P streaming traffic is becoming a major 103 type of Internet traffic in some Internet networks. For example, 104 according to the statistics of a major Chinese ISP, the traffic 105 generated by P2P streaming applications exceeded 50% of the total 106 backbone traffic during peak time in 2008. There were reports that 107 major video distributors such as Youtube [youtube] and tudou [tudou] 108 are conducting trials of using P2P streaming as a component of their 109 delivery infrastructures. 110 Given the increasing integration of P2P streaming into the global 111 content delivery infrastructure, the lacking of an open, standard P2P 112 streaming protocol becomes a major missing component in the Internet 113 protocol stack. Multiple, similar but proprietary P2P streaming 114 protocols result in repetitious development efforts and lock-in 115 effects. More importantly, it leads to substantial difficulties when 116 integrating P2P streaming as an integral component of a global 117 content delivery infrastructure. For example, proprietary P2P 118 streaming protocols do not integrate well with existing cache and 119 other edge infrastructures. 120 1.1. Research or Engineering 121 As [P2PStreamSurvey] identifies, there exist multiple proprietary P2P 122 streaming systemsincluding PPLive, PPstream, UUsee, Pando, abacast, 123 and Coolstreaming. A natural question to ask is whether the 124 development of P2P streaming is mature and ready for standardization. 125 We admit that P2P streaming will continue to improve and evolve. 126 However, our investigation shows that existing P2P streaming systems 127 are largely converging, sharing similar architecture and signaling 128 protocols [draft-zhang-ppsp-protocol-comparison-measurement-00]. The 129 competition of P2P streaming vendors become increasingly on contents. 130 1.2. Objective and outline 131 Our objective is to develop a standard P2P streaming protocol that 132 can operate in both fixed and mobile Internet. The protocol will 133 serve as an enabling technology, building on the development 134 experiences of existing P2P streaming protocols. It will integrate 135 with IETF efforts on distributed resource location, traffic 136 localization, and streaming control mechanisms. It allows effective 137 integration with edge infrastructures such as cache and mobile edge 138 equipment. 139 This document provides a problem statement for designing PPSP. The 140 rest of the document is organized as follows. In Section 2, we 141 introduce terminologies. In Section 3, we identify the current 142 problems in providing a scalable and economical streaming system.In 143 Section 4, we describe the main issues to consider when designing 144 PPSP. In Section 5, we outline the main scope of work. 146 2. Definitions 147 The following terms have special meaning in the definition of the 148 Peer to Peer Streaming Protocol (PPSP) problem. 149 Tracker: A dedicated server who is in charge of maintaining peer list 150 and replying peer request for peer selection. 151 Peer: A peer refers to a participant in a P2P streaming system who 152 acts both as "client" and "server". 153 Chunk: A chunk is a basic unit of partitioned streaming, which is 154 used for the purpose of storage and advertising to neighbors what 155 parts of a movie a peer holds [Sigcomm:P2P streaming]. 156 Bitmap: Bitmap is a table indicating which chunks a peer has. 157 Peering networks: Two directly connected Internet Service Providers. 158 Apart from infrastructure and operational costs, peering traffic is 159 usually free, within the contract of a peering agreement [draft- 160 marocco-alto-problem-statement-03]. 162 3. Problem Statement Scope 163 We perceive a number of problems related to scalable and economical 164 streaming on the Internet. The major issues are the following: 165 1) The difficulty of an open PPSP due to the existence of many 166 proprietary and non-interoperable protocols in current p2p 167 streaming applications; 168 2) The difficulty of integrating current edge equipments such as 169 cache and content distribution network (CDN) nodes into P2P 170 streaming; 171 3) The difficulty of integrating related protocols into P2P 172 streaming, like RELOAD,ALTO,RTSP, which is beyond current P2P 173 streaming usage; 174 4) The lack of a standard solution for scalable and economical 175 streaming signaling interaction suitable both for fixed internet 176 and mobile Internet; a related problem is that the difficulty of 177 deploying p2p streaming in mobile Internet; 178 The subsections below discuss these problems in more detail. 180 3.1. Proprietary protocols and an open PPSP 181 Currently there exist some P2P streaming systems like PPLive, 182 PPstream, UUsee, Pando[Pando] and 183 Coolstreaming[Coolstreaming].Although using similar system 184 architecture as well as signaling interaction processes[draft-zhang- 185 ppsp-protocol-comparison-measurement-00], due to their proprietary 186 protocols, it's hard to develop an open PPSP protocol without 187 checking all the typical P2P streaming systems, identifying the key 188 issues and considering all the requirements. 190 3.2. Integrating cache and CDN into P2P streaming 191 To make P2P streaming stable and traffic local enough, cache and 192 other edge infrastructure is a very promising means [draft-marocco- 193 alto-problem-statement-03]. 194 However there are a few obstacles in deploying P2P caches [HTPT]: 195 firstly, P2P caching systems are likely to be very complicated. 196 Unlike web traffic standardized in using HTTP transport through few 197 dedicated ports like 80, there is no a standard P2P protocol and 198 every P2P protocol uses its own port. Therefore, P2P caching systems 199 are forced to take an ad hoc approach by enumerating and handling 200 every P2P protocol. Another drawback of this ad hoc approach is the 201 requirement of regular update of the P2P cache engines to handle 202 newly emerged popular P2P protocols. Secondly, extra, possibly huge, 203 investment is required for the equipment and facility purchase and 204 also the administrative cost. 205 If we can utilize the existing cache and other edge equipments like 206 CDN nodes, the cost can be heavily reduced. Meanwhile because it's 207 widely used, the performance of P2P streaming can increase much. 208 Therefore how to utilize the edge infrastructure is a big issue. 209 Current web cache or other widely deployed edge equipments like CDN 210 doesn't support P2P streaming yet[HTPT]. 212 3.3. Integrating existing protocols into P2P streaming 213 There are several protocols related to p2p streaming having been or 214 being defined in IETF, including RELAOD,ALTO,RTSP,etc.., where 215 P2PSIP,ALTO and MMusic are most related WGs. Unfortunately there is 216 no one protocol above considered by current P2P streaming 217 applications. 218 We claim that PPSP is not a stand-alone protocol. It could and should 219 integrate with the existing related protocols to the largest extent. 220 We analyze several protocols PPSP may relate to in detail in section4. 222 3.4. Mobility and wireless issue 223 Mobility and wireless becomes a very important feather to support in 224 future internet [GENI],[FIND]. Some operators have also started 225 research projects on mobile and wireless Internet. For example, China 226 Mobile came out with its DSN (distributed services network) strategy 227 last year to build its mobile Internet [draft-zhang-ppsp-dsn- 228 introduction-00]. 229 Along with the introduction of mobile and wireless characteristics 230 into Internet, mobile streaming will become more and more 231 popular[MobileTV].In Korea the mobilTV subscriber is 17 million 232 accounting one third of the mobile subscriber. In Italy there are 1 233 million mobileTV users. In the period of Beijing Olympic games, there 234 are more than 1 million usage of China mobile's mobileTV. 235 Most of current mobileTV are developed in client/server model. It's a 236 natural idea to increase its scalability and decrease the cost by 237 deploying P2P mobile streaming. 239 However there are a lot of differences in mobile/wireless Internet 240 compared with fixed Internet environment. This makes it hard to copy 241 current P2P streaming protocol in fixed Internet environment. 242 3.4.1. End to end communication is harder 243 Unlike fixed Internet, it's difficult to realize end-to-end 244 communication in mobile Internet. Mobile terminals cannot connect 245 with each other directly. The connection must be set up by 246 mobile/wireless access nodes. Therefore mobile terminals are hard to 247 become peers without the cooperation of mobile/wireless access 248 equipments. It's obviously a heavy burden for the mobile/wireless 249 access points. 250 +-------------------------------------------------------------------+ 251 | | 252 | +-------+ | 253 | | Cache | | 254 | +-------+ | 255 | ^ | 256 | | | 257 | Peerlist V | 258 | +---------------+ +----+ +-----------+ | 259 | | Tracker |<---->|PEER|<---->| AP |Bottleneck | 260 | +---------------+ +----+ +-----------+ | 261 | ^ ^ ^ ^ | 262 | | | | Low | | 263 | | | |Bandwidth| | 264 | V V V V | 265 | +---+ End-end +---+ +------+ +------+ | 266 | |PC |<------> |PC | |Mobile|<--> |Mobile| | 267 | | | works | | |Phone | ? |Phone | | 268 | +---+ Well +---+ +------+ +------+ | 269 | | 270 | | 271 +-------------------------------------------------------------------+ 273 Figure 1 Mobile Internet communication 274 3.4.2. Limited Bandwidth resource 275 Even if end-to-end communication is ensured, there are still problems 276 for P2P mobile streaming.As shown in Figure1, the following bandwidth 277 is limited and the transmission cost is relatively high: 278 a) between mobile terminals and mobile access nodes; 280 b) between mobile access node 281 c) between mobile network to fixed network. 282 It raises some requirements for PPSP: 283 1)The overhead of PPSP cannot be much. Because PPSP is a signaling 284 protocol, the overhead refers to the ratio of signaling traffic 285 with respect to overall streaming traffic. Different solutions 286 have different overhead. [Computer Networks-Traffic]analyzes four 287 P2P streaming overhead, namely PPLive,PPStream,SOPCast and 288 TVAnts.There is a tradeoff consideration in PPSP. We know that 289 frequent exchange in bitmap may cause a big overhead but it also 290 enables a small peer cache to keep the smooth play of the program. 291 On one hand, the overhead should be minimum to reduce the traffic 292 and increase the efficiency so the bitmap exchange frequency 293 should be small. On the other hand, a mobile terminal has usually 294 small cache size so the bitmap exchange frequency should be large. 295 How to solve the conflict and balance between the cache size and 296 bitmap exchange frequency is a problem PPSP may face with. 297 2) Cross-domain traffic must be reduced. For most mobile Internet 298 domains, their network scale is rather smaller compared with the Tier1 299 and Tier2 peering networks. Currently peering networks are free from 300 the cross-traffic. However the low-tier ISPs have to pay for dual- 301 directional traffic fee even it's a traffic initiated from higher tier 302 ISPs. It makes mobile Internet provider worse in case P2P streaming 303 applications generate great traffic with a low-cross-domain bandwidth. 304 3.4.3. Other difference 305 Mobility, low battery and capability of mobile terminals make us 306 considering more factors in peer selection to ensure smooth streaming. 307 A new protocol might therefore allow more information to report for 308 trackers to do peer selection. 310 4. Design Issues 311 This section introduces key issues when designing PPSP. 312 4.1. Architecture Choice 313 There are multiple proposed p2p streaming solutions. Some are used in 314 practice and while others are popular in theory. The basic idea of 315 P2P streaming is to partition streaming into chunks and peers are 316 used in relaying chunk transmission. The solutions can be categorized 317 by tree-based and mesh-based [Survey]. The former is "pushing" chunks 318 to the audience and the latter is enabling the audience to "pulls" the 319 desired chunks from the peers who has. 320 In the tree-based p2p streaming, tree construction and maintenance 321 can be done in either a centralized or a distributed fashion [Survey]. 322 In the mesh-based p2p streaming, no specific topology maintenance is 323 needed. The task is how to locate and retrieve real-time data from 324 multiple sources with different chunks for a streaming. In order to 325 realize this, each peer has to actively locate cache and exchange 326 chunks from other peers by the guidance of the tracker. 327 The biggest challenge in tree-based p2p streaming is two-fold: First, 328 tree-based streaming still cannot recovery fast enough to handle 329 frequent peer churn[Mesh and Multi-tree comparison].Second, peers at 330 the higher level of the tree are required to have sufficient upload 331 capacity to support the streaming of their children peers. If it 332 were not the case, the performance will dramatically be deteriorated. 333 On the contrary mesh-based p2p streaming is widely used to overcome 334 these drawbacks for real deployment, like pplive, ppstream, 335 coolstreaming, etc,.. 336 4.2. Integration with existing protocols 337 PPSP will not be a stand-alone protocol. A major advantage of a 338 standard protocol is that we can explicit consider its interactions 339 with other protocols, and design for an integrated system. 340 In particular, we identify that PPSP will interact with the following 341 protocols: RELAOD, ALTO, and RTSP, where P2PSIP, ALTO and MMusic are 342 the most related WGs. 343 4.2.1. Integration with RELOAD 344 RELOAD defined by P2PSIP deals with resource location in end to end 345 commutation. The iterative and recursive routing process in RELOAD is 346 shown in Fig4, which is different from PPSP. That is, the data stored 347 in RELOAD is user profile data and the requester knows exactly what 348 the data is (e.g., the location of Alice is 5678). While in PPSP, 349 there are many peers storing different data pieces of "CNN Live". The 350 only thing a peer must know is the metadata of the movie. A gossip 351 protocol to communicate with other peers is needed to get the real 352 data quickly. 353 The P2PSIP routing clarification is to state that it may don't 354 suit with tracker based topology(tree or meshed).So we draw both 355 routings. 356 Alice 357 (5678) 358 | +------------------------+ 359 | | P2PSIP DHT overlay | 360 | | (RELOAD) | 361 | FetchReq(Alice) | +---------------+ | 362 |----------------->|---->| Peer | | 363 | | +--| | | 364 | | | +---------------+ | 365 | | | ^ ^ | 366 | | | 1|2 3|4 | 367 | | | V V | 368 | | | +----+ +----+ | 369 | | | |Peer| |Peer| | 370 | | | +----+ +----+ | 371 | FetchAns(1234) | | | 372 |<-----------------|<-+ | 373 | | | Bob 374 | AppAttach(1234) | | (1234) 375 |----------------->| -- -- -- -- -- -- -- --| --------> | 376 |<-----------------| -- -- -- -- -- -- -- --| <-------- | 377 | +------------------------+ | 378 | | 379 | <------------------ ICE Checks -------------------> | 380 | INVITE -------------------------------------------> | 382 Alice 383 (5678) 384 | +------------------------+ 385 | | P2PSIP DHT overlay | 386 | | (RELOAD) | 387 | FetchReq(Alice) | +---------------+ | 388 |----------------->|---->| Peer | | 389 | | +--| | | 390 | | | +---------------+ | 391 | | | | | | 392 | | | 1| |3 | 393 | | | V V | 394 | | | +----+ 2 +----+ | 395 | | | |Peer|-->|Peer| | 396 | | | +----+ +----+ | 397 | FetchAns(1234) | | | 398 |<-----------------|<-+ | 399 | | | Bob 400 | AppAttach(1234) | | (1234) 401 |----------------->| -- -- -- -- -- -- -- --| --------> | 402 |<-----------------| -- -- -- -- -- -- -- --| <-------- | 403 | +------------------------+ | 404 | | 405 | <------------------ ICE Checks -------------------> | 406 | INVITE -------------------------------------------> | 408 Figure 2 P2PSIP process 409 The biggest difference between P2PSIP and PPSP lies in their 410 different search efficiency requirements. PPSP requires retrieving 411 real-time/para real-time data with strict timeline. DHT based 412 topology supported in RELAOD may not be suitable for peer information 413 storage and retrival.There are some reasons as follows: 414 First, the amount of registered chunks at the same time is great, 415 e.g., several hundred chunks in the cache. Therefore too frequent PUT 416 operations occur in each peer. 417 Second, the stored chunk information will be invalid very quick, e.g., 418 several minutes in live streaming. Different from VoD streaming, 419 chunk information is of no use if the requested time is too late to 420 exceed the threshold of the cached content time-out.If every peer 421 continuously publishes the dynamic changed chunk information, a big 422 burden will be generated. 423 Although P2PSIP doesn't fit for streaming peer organization, it can 424 be deployed in PPSP environment to some extent. 426 First, the topology organization of DHT defined in RELOAD can be used 427 to organize multiple trackers. Due to the large population, some 428 trackers may cooperatively serve a channel/file. Considering the 429 great amount of channels, there are many trackers in practice. 430 Because the search time of which channel/file the tracker stores 431 accounts small percentage in the whole searching procedure, DHT can 432 be used to query for peer list in case of thousand of channels or 433 million of files which are hard to use one tracker. 434 Second, there is a detailed solution for Firewall/NAT transversal in 435 in RELOAD. PPSP faces with the same problem, although not as serious 436 as RELAOD because there are lots of peer candidates with public 437 addresses. But we can definitely reuse RELAOD in case of NAT/Firewall 438 transversal which may occur in mobile environment. 439 4.2.2. Integration with ALTO 440 ALTO is to define a protocol realizing local traffic mostly for P2P 441 applications. The goal of an ALTO solution would be to help peers to 442 find the best sources and the best destinations for media flows they 443 receive and relay. In [draft-marocco-alto-problem-statement-03], the 444 authors mentioned p2p live streaming that can benefit from ALTO 445 service. 446 As we have seen in Section 1, P2P streaming traffic account much on 447 the Internet backbone. PPSP has to consider operator-friendly ways to 448 reduce the cross-backbone traffic in order to control the 449 transmission cost. ALTO is a good candidate to do so. 450 ALTO provides a 3rd party to provide peer locality information based 451 on the premise that the 3rd party has the knowledge of the network 452 topology. In addition there may have extra traffic localization means, 453 e.g., in [draft-zhang-alto-traceroute-00], peers can cluster the 454 nearby peers by simple and lightweight measurements. We can use this 455 mechanism in peer selection to further reduce the traffic. 456 4.2.3. Encapsulating RTSP 457 At a first sight, the function of PPSP protocol is similar to 458 traditional client/server streaming control protocols, RTSP. But in 459 fact RTSP don't involve the problems PPSP has. 460 In RTSP, the focus is to control the streaming, like PLAY, PAUSE; 461 however PPSP focuses on signaling peers for real-time resource 462 discovery, merge and synchronization instead of how to realize 463 streaming control. 465 On the other hand, considering the prevalence of RTSP, it can also be 466 reused in clients without installing PPSP-compatible software to use 467 P2P streaming service. 468 The basic idea in that is to set up a proxy node (e.g., using a cache) 469 which can act as a RTSP server who is actually a peer of PPSP. 470 4.2.4. Edge Device such as Cache Integration 471 As stated in Section 3, if the widely deployed web cache and CDN 472 nodes can be reused in p2p streaming, the video quality, local 473 traffic and some security problems may be better solved.[HTPT] 474 proposes a solution similar to what we propose in section 4.5 to 475 encapsulate and transport them using the HTTP protocol so that they 476 are cacheable. 478 5. Scope of Work 479 We propose to develop an open peer to peer streaming protocol, namely 480 PPSP. The basic task of PPSP is to define a protocol of locating and 481 transmitting real-time data efficiently from multiple sources with 482 different pieces in peer to peer environment. 484 5.1 Architecture of PPSP 485 PPSP focuses on how to negotiate with un-preassigned peers for needed 486 chunks. Therefore, PPSP is mainly a signaling protocol and the 487 protocol stack of PPSP is shown in Figure 3. 488 +-------------------------------------------------------------------+ 489 | +---------------------------------------------------------------+ | 490 | | Application Layer | | 491 | +---------------------------------------------------------------+ | 492 |===================================================================+ 493 | Play-out Layer | 494 | +---------+ +----------+ +----------+ | 495 | | Start | | Pause | | Stop | | 496 | +---------+ +----------+ +----------+ | 497 |===================================================================| 498 | Information Layer | 499 | +-------------+ +----------+ +------------+ | 500 | |Registration | | Report | | Statistics | | 501 | +-------------+ +----------+ +------------+ | 502 |===================================================================| 503 | Communication Layer | 504 | +-----------------------+ +-------------------------------+ | 505 | | Topology creation | |Head Node/Tracker Communication| | 506 | +-----------------------+ +-------------------------------+ | 507 | +-----------------------+ +-------------------------------+ | 508 | |Neighbour Communication| | Bootstrap | | 509 | +-----------------------+ +-------------------------------+ | 510 |===================================================================| 511 | +---------------------------------------------------------------+ | 512 | | Transport Layer | | 513 | +---------------------------------------------------------------+ | 514 +-------------------------------------------------------------------+ 516 Figure 3 PPSP Position in Protocol Stack 517 It can be divided into 5 layers: 518 1) Transport Layer is responsible for data transmission between peers, 519 UDP,TCP or other protocols can be used; 520 2) Communication layer is the key layer in PPSP, including four 521 components: 523 a)Topology creation is a component each peer has to request to 524 join the overlay, like tree or mesh; 525 b)Head Node/Tracker Communication is a component each peer 526 continually to get peer list or peer information report to the 527 tracker or tree maintenance by the head node. 528 c)Neighbor Communication is a component that peers exchange 529 bitmap in mesh or other neighbor availability information for loop 530 avoidance in tree. 531 d)Bootstrap is a component to introduce a newly joined node to 532 get the tracker or head node information since there may be multiple 533 trackers or head nodes. It keeps monitoring the trackers and head 534 nodes. 535 3) Information layer is a layer for peer and content information 536 collection and management, which helps to improve the system 537 performance from the global view of point. 538 a)Registration is a component that enables nodes register to the system, 539 publish the contents it wants to broadcast through the P2P streaming 540 system.The information may include but not limit the scope of the 541 following items: the content description, content type, creation time, 542 the node information such as physical location, IP address and network 543 condition as well as program advertisment policies. 544 b)Report is a component that enables peers to report their useful 545 information to the head node or tracker. These information exclude 546 those basic message between peers and head nodes or trackers in the 547 communication layer. The information may include peer inbound and 548 outbound traffic, amount of neighbor peers,peer health degree as well 549 as the video quality parameters. 550 c)Statistics is a component that enables the tracker or head node to 551 manage the aggregated system information for global control in upload 552 bandwidth consumption,overhead consumption and other regards. 553 4) Play-out layer is a layer to control the action of the media 554 brower/player just like RTSP.One point needed to notice is that in 555 tracker-based ppsp applications, there is a local media player to 556 control the program play. The content is locally cached. Therefore no 557 network related commands like RTSP is needed. 558 5) Application layer is the top layer in the ISO/OSI model,where PPSP 559 application exists. 561 5.2 Scope of PPSP 563 In order to locate real-time data efficiently from multiple sources 564 with different pieces, we have to solve the following problems: 565 1) To standardize the architecture for locating the data efficiently. 566 Tracker-based structure is widely used in current p2p streaming 567 practice. However some tracker-less structures like DHT peer 568 management solutions are also proposed. We need to explore the bast 569 practice for p2p streaming; 570 2) To standardize the signaling interaction process. 571 In this part we actually want to standardize client registration 572 process (analogous to TCP 3-way handshake procedure), client 573 information exchange process (analogous to SIP session setup process) 574 and client report process. 575 The current tracker-based means is a two-step searching, i.e., peer 576 reporting to tracker coarse information about it has. Once the 577 tracker is asked, it informs peer of the coarse information; the 578 grain information is achieved by peers exchanging bitmap each other. 579 Some other means, e.g., peer reporting to tracker grain information 580 directly and tracker informs peer of the exact information or DHT 581 based searching, should be evaluated. In each proposal we also need 582 to define the message format in the interactions. 583 We draw a protocol interaction based on the proposed component 584 architecture with different types of nodes in tracker-based PPSP 585 systems. 586 The figure is as follows: 588 +-------------------------------------------------------------------+ 589 | | 590 | +-------+Bootstrap(http)+---------+ +--------+| 591 | | Peer1 |-------------->|Bootstrap| |Content || 592 | +-------+<------+ +---------+ |Provider|| 593 | | | ^ ^ | +--------+| 594 | | | | | | Registration(http)^ | 595 | | | | | | +------------+ | 596 | |Chunk| Topology| |Topology |PeerRequest(http) | | 597 | |-----| creation| |creation +----------------+ | | 598 | |Chunk| (PPSP) | | (PPSP) PeerReport(http) V V | 599 | |-----| | | +---------+ +-------|| 600 | |Chunk| | | | Tracker/|-----|Tracker|| 601 | |-----|Neighbour| |Neighbour |Head Node|<--+ +-------+| 602 | | |Communication Communication +---------+ | ^ | 603 | | | (PPSP) | |(PPSP) | ^ | |(RELOAD) 604 | | | | | | |Statistic| | | 605 | V V | +---------+ V | 606 | +-----+ +-----+ +------------------+ | 607 | |Peer2| |Peer2| | Tracker | | 608 | +-----+ +-----+ +------------------+ | 609 | | 610 | | 611 | | 612 +-------------------------------------------------------------------+ 614 Figure 4: Protocol interaction of PPSP systems 615 At a primary consideration, some existing and developing protocols 616 can be reused in some of the interactions ,e.g, HTTP in content 617 registration and RELAOD in multiple trackers topology orgnization. 618 And other interactions like topology creation and neighbor 619 communication, need PPSP to support.This is the initial step we need 620 to develop in PPSP. 621 Other interactions, like peer and tracker communication, may reuse 622 http or develop new PPSP protocols after evaluating the efficiency in 623 PPSP scenarios. 624 3) To discuss how to incorporate other node information such as 625 online time, link status, node capability, battery information and 626 some application requirements parameters into the protocol to expand 627 the peer selection. 629 In this part, we actually want to expand to standardize PPSP message 630 headers (analogous to IP header definition) and PPSP metadata format 631 (analogous to SIP header definition). 633 6. Security Considerations 634 PPSP has a similar assumption in peer privacy as P2PSIP, i.e., all 635 participants in the system are issued unique identities and 636 credentials through some mechanism not in the scope of this working 637 group, such as a centralized server. Hence the WG will not attempt a 638 solution to these issues for P2P streaming networks in general. 639 However PPSP has some unique privacy issue different from P2PSIP: 640 1) The content published by peers may not be checked by centralized 641 certificating server because of the high amount. Therefore P2P 642 streaming network faces with more serious malicious content 643 distribution danger than P2PSIP. 644 2) Content Pollution is a phenomenon P2PSIP may not meet with. But 645 these is a common problem faced by P2P streaming and file sharing. 646 It's recorded that there are about 50% of the content is polluted in 647 file sharing applications. Although it's not as serious as file 648 sharing content pollution, it's still a big issue P2P streaming 649 applications face with. 650 3) Because there is a tracker server who is critical to the P2P 651 streaming systems. It has more probability to launch attacks to the 652 tracker. 653 PPSP may include some security mechanisms to prevent malicious nodes 654 to pollute or launch attacks to the tracker. Security issues in PPSP 655 need to be further investigated. 656 7. Acknowledgments 657 We have to acknowledge many people. For the record: D.Bryan from 658 SIPeerior;E.Marocco from TI;V.Gurbani from AT&T;R.Even from 659 Huawei;H.Zhang from NEC Labs,USA;C.Schmidt and L.Xiao from 660 NSN;C.Williams from ZTE;V.Pasualfrom Tekelec; X.Zhang from PPlive; 661 H.Deng from China Mobile;and J.Lei from Univ. of Goettingen. 662 8. References 663 [Cisco] Approaching the Zettabyte Era by Cisco. 664 [PPLive] www.pplive.com 665 [PPStream] www.ppstream.com 666 [UUSee] www.uusee.com 668 [youtube] www.youtube.com 669 [tudou] www.tudou.com 670 [CNN] www.cnn.com 671 [Octoshape] www.octoshape.com 672 [ATT]http://mobile.sooyuu.com/Article/content/200905/217315094629281_ 673 1.shtml 674 [Sigcomm:P2P streaming]Challenges, Design and Analysis of a Large- 675 scale P2P-VoD System,Yan Huang et al, Sigcomm08. 676 [draft-marocco-alto-problem-statement-03], Application-Layer Traffic 677 Optimization (ALTO) Problem Statement, E. Marocco et al, draft- 678 marocco-alto-problem-statement-03 679 [Pando]www.pando.com 680 [CoolStreaming] CoolStreaming/DONet: A Data-Driven Overlay Network 681 for Efficient Live Media Streaming, Xinyan Zhang et al, 682 [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen 683 et al, 684 [draft-zhang-ppsp-protocol-comparison-measurement-00] 685 www.ietf.org/internet-drafts/draft-zhang-ppsp-protocol-comparison- 686 measurement-00.txt 687 [GENI] www.geni.net 688 [FIND]www.nets-find.net 689 [draft-zhang-ppsp-dsn-introduction-00]www.ietf.org/internet- 690 draft/draft-zhang-ppsp-dsn-introduction-00.txt 691 [MobileTV] MobileTV,Turning in or switching off, Arthur D. Little 692 [Computer Networks:Traffic] Traffic analysis of peer-to-peer IPTV 693 communities, Thomas Silverston et al, Computer Networks, 53 (2009) 694 470-484 695 [Survey]A survey on peer-to-peer video streaming systems,Yong Liu et 696 al, Peer-to-Peer Netw Appl (2008) 1:18-28,Springer. 698 [draft-zhang-alto-traceroute-00] www.ietf.org/internet-draft/draft- 699 zhang-alto-traceroute-00.txt 700 [Mesh and Muti-tree comparison] Source vs Data-driven Approach for Live 701 P2P Streaming.Thomas Silverston and Olivier Fourmaux.Proceedings of the 702 international Conference on Networking,international Conference on Systems, 703 and international Conference on Mobile Communications and Learning 704 Technologies(ICNICONSMCL'06) 706 Author's Addresses 707 Yunfei Zhang 708 China Mobile Communication Corporation 709 zhangyunfei@chinamobile.com 711 Ning Zong 712 Huawei Technologies Co., Ltd. 713 zongning@huawei.com 715 Gonzalo Camarillo 716 Ericsson 717 Gonzalo.Camarillo@ericsson.com 719 James Seng 720 PPLive 721 james.seng@pplive.com 723 Richard Yang 724 Yale University 725 yry@cs.yale.edu