idnits 2.17.1 draft-zhang-ppsp-problem-statement-02.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 14 instances of too long lines in the document, the longest one being 27 characters 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 (May 27, 2009) is 5448 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 66, but not defined == Missing Reference: 'PPstream' is mentioned on line 80, but not defined == Missing Reference: 'P2PStreamSurvey' is mentioned on line 103, but not defined == Missing Reference: 'Pando' is mentioned on line 181, but not defined == Missing Reference: 'Coolstreaming' is mentioned on line 182, but not defined == Missing Reference: 'HTPT' is mentioned on line 467, but not defined == Missing Reference: 'FIND' is mentioned on line 230, but not defined == Missing Reference: 'Survey' is mentioned on line 347, but not defined == Unused Reference: 'PPStream' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'Octoshape' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'CoolStreaming' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'HPTP' is defined on line 597, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'HPTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'GENI' -- Possible downref: Non-RFC (?) normative reference: ref. 'MobileTV' Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 11 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 12 Expires: November 2009 May 27, 2009 14 Problem Statement of P2P Streaming Protocol (PPSP) 15 draft-zhang-ppsp-problem-statement-02.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on November 27, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your 48 rights and restrictions with respect to this document. 50 Abstract 52 We propose to develop an open peer-to-peer (P2P) streaming protocol 53 named PPSP. This document describes problem related to PPSP and 54 outlines considerations that have to be taken in account when 55 arriving at equitable solutions. 57 Table of Contents 58 1. Introduction 60 Streaming traffic is among the fastest growing traffic on the 61 Internet. In a recent white paper, Cisco predicts that by 2012, 90% 62 of all Internet traffic will be video [Cisco]. 64 There are two basic architectures for delivering streaming traffic on 65 the global Internet: the client-server paradigm and the peer to peer 66 (P2P) paradigm [P2PStreamingSurvey]. A particular advantage of the 67 P2P paradigm over the client-server paradigm is its scalability. As 68 an example, PPLive [PPLive], one of the largest P2P streaming vendors, 69 is able to distribute large-scale, live streaming programs such as 70 the CCTV Spring Festival Gala to more than 2 million users with only 71 a handful of servers. CNN[CNN] reported that P2P streaming by 72 Octoshape played a major role in its distribution of the historical 73 inauguration address of President Obama. It is well demonstrated in 74 practice that P2P streaming can deliver videos encoded at a rate of 75 about 400 Kbps, in the presence of rapid user joins/leaves, with 76 positive user experiences. 78 With the preceding technical advantages, P2P streaming is seeing 79 rapid deployment. Large P2P streaming applications such as PPLive 80 [PPLive], PPstream [PPstream] and UUSee [UUSee] each has a user base 81 exceeding 100 millions. P2P streaming traffic is becoming a major 82 type of Internet traffic in some Internet networks. For example, 83 according to the statistics of a major Chinese ISP, the traffic 84 generated by P2P streaming applications exceeded 50% of the total 85 backbone traffic during peak time in 2008. There were reports that 86 major video distributors such as Youtube [youtube] and tudou [tudou] 87 are conducting trials of using P2P streaming as a component of their 88 delivery infrastructures. 90 Given the increasing integration of P2P streaming into the global 91 content delivery infrastructure, the lacking of an open, standard P2P 92 streaming protocol becomes a major missing component in the Internet 93 protocol stack. Multiple, similar but proprietary P2P streaming 94 protocols result in repetitious development efforts and lock-in 95 effects. More importantly, it leads to substantial difficulties when 96 integrating P2P streaming as an integral component of a global 97 content delivery infrastructure. For example, proprietary P2P 98 streaming protocols do not integrate well with existing cache and 99 other edge infrastructures. 101 1.1. Research or Engineering 103 As [P2PStreamSurvey] identifies, there exist multiple proprietary P2P 104 streaming systems including PPLive, PPstream, UUsee, Pando, abacast, 105 and Coolstreaming. A natural question to ask is whether the 106 development of P2P streaming is mature and ready for standardization. 107 We admit that P2P streaming will continue to improve and evolve. 108 However, our investigation shows that existing P2P streaming systems 109 are largely converging, sharing similar architecture and signaling 110 protocols [draft-zhang-ppsp-protocol-comparison-measurement-00]. The 111 competition of P2P streaming vendors become increasingly on contents. 113 1.2. Objective and outline 115 Our objective is to develop a standard P2P streaming protocol that 116 can operate in both fixed and mobile Internet. The protocol will 117 serve as an enabling technology, building on the development 118 experiences of existing P2P streaming protocols. It will integrate 119 with IETF efforts on distributed resource location, traffic 120 localization, and streaming control mechanisms. It allows effective 121 integration with edge infrastructures such as cache and mobile edge 122 equipment. 124 This document provides a problem statement for designing PPSP. The 125 rest of the document is organized as follows. In Section 2, we 126 introduce terminologies. In Section 3, we identify key use cases 127 where a standard P2P streaming protocol can facilitate the 128 integration of P2P streaming into the network infrastructure, and 129 therefore benefit both the content distributors and the networks. In 130 Section 4, we describe the main issues to consider when designing 131 PPSP. In Section 5, we outline the main scope of work. 133 2. Definitions 135 The following terms have special meaning in the definition of thePeer 136 to Peer Streaming Protocol (PPSP) problem. 138 Tracker: A dedicated server who is in charge of maintaining peer list 139 and replying peer request for peer selection. 141 Peer: A peer refers to a participant in a P2P streaming system who 142 acts both as ''client'' and ''server''. 144 Chunk: A chunk is a basic unit of partitioned streaming, which is 145 used for the purpose of storage and advertising to neighbors what 146 parts of a movie a peer holds [Sigcomm:P2P streaming]. 148 Bitmap: Bitmap is a table indicating which chunks a peer has. 150 Peering networks: Two directly connected Internet Service Providers. 151 Apart from infrastructure and operational costs, peering traffic is 152 usually free, within the contract of a peering a greement [draft- 153 marocco-alto-problem-statement-03]. 155 3. Problem Statement Scope 157 We perceive a number of problems related to scalable and economical 158 streaming on the Internet. The major issues are the following: 160 1) The difficulty of an open PPSP due to the existence of many 161 proprietary and non-interoperable protocols in current p2p 162 streaming applications; 164 2) The difficulty of integrating current edge equipments such as 165 cache and content distribution network (CDN) nodes into P2P 166 streaming; 168 3) The difficulty of integrating related protocols into P2P streaming, 169 like RELOAD,ALTO,RTSP, which is beyond current P2P streaming usage; 171 4) The lack of a standard solution for scalable and economical 172 streaming signaling interaction suitable both for fixed internet 173 and mobile Internet; a related problem is that the difficulty of 174 deploying p2p streaming in mobile Internet; 176 The subsections below discuss these problems in more detail. 178 3.1. Proprietary protocols and an open PPSP 180 Currently there exist some P2P streaming systems like PPLive, 181 PPstream, UUsee, Pando[Pando] and 182 Coolstreaming[Coolstreaming].Although using similar system 183 architecture as well as signaling interaction processes[draft-zhang- 184 ppsp-protocol-comparison-measurement-00], due to their proprietary 185 protocols, it's hard to develop an open PPSP protocol without 186 checking all the typical P2P streaming systems, identifying the key 187 issues and considering all the requirements. 189 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]. 195 However there are a few obstacles in deploying P2P caches [HTPT]: 196 firstly, P2P caching systems are likely to be very complicated. 197 Unlike web traffic standardized in using HTTP transport through few 198 dedicated ports like 80, there is no a standard P2P protocol and 199 every P2P protocol uses its own port. Therefore, P2P caching systems 200 are forced to take an ad hoc approach by enumerating and handling 201 every P2P protocol. Another drawback of this ad hoc approach is the 202 requirement of regular update of the P2P cache engines to handle 203 newly emerged popular P2P protocols. Secondly, extra, possibly huge, 204 investment is required for the equipment and facility purchase and 205 also the administrative cost. 207 If we can utilize the existing cache and other edge equipments like 208 CDN nodes, the cost can be heavily reduced. Meanwhile because it's 209 widely used, the performance of P2P streaming can increase much. 210 Therefore how to utilize the edge infrastructure is a big issue. 211 Current web cache or other widely deployed edge equipments like CDN 212 doesn't support P2P streaming yet[HTPT]. 214 3.3. Integrating existing protocols into P2P streaming 216 There are several protocols related to p2p streaming having been or 217 being defined in IETF, including RELAOD,ALTO,RTSP,etc.., where 218 P2PSIP,ALTO and MMusic are most related WGs. Unfortunately there is 219 no one protocol above considered by current P2P streaming 220 applications. 222 We claim that PPSP is not a stand-alone protocol. It could and should 223 integrate with the existing related protocols to the largest extent. 225 We analyze several protocols PPSP may relate to in detail in section4. 227 3.4. Mobility and wireless issue 229 Mobility and wireless becomes a very important feather to support in 230 future internet [GENI],[FIND]. Some operators have also started 231 research projects on mobile and wireless Internet. For example, China 232 Mobile came out with its DSN (distributed services network) strategy 233 last year to build its mobile Internet [draft-zhang-ppsp-dsn- 234 introduction-00]. 236 Along with the introduction of mobile and wireless characteristics 237 into Internet, mobile streaming will become more and more 238 popular[MobileTV].In Korea the mobilTV subscriber is 17 million 239 accounting one third of the mobile subscriber. In Italy there are 1 240 million mobileTV users. In the period of Beijing Olympic games, there 241 are more than 1 million usage of China mobile's mobileTV. 243 Most of current mobileTV are developed in client/server model. It's a 244 natural idea to increase its scalability and decrease the cost by 245 deploying P2P mobile streaming. 247 However there are a lot of differences in mobile/wireless Internet 248 compared with fixed Internet environment. This makes it hard to copy 249 current P2P streaming protocol in fixed Internet environment. 251 3.4.1. End to end communication is harder 253 Unlike fixed Internet, it's difficult to realize end-to-end 254 communication in mobile Internet. Mobile terminals cannot connect 255 with each other directly. The connection must be set up by 256 mobile/wireless access nodes. Therefore mobile terminals are hard to 257 become peers without the cooperation of mobile/wireless access 258 equipments. It's obviously a heavy burden for the mobile/wireless 259 access points. 261 +------------------------------------------------------------+ 262 | | 263 | +-------+ | 264 | | Cache | | 265 | +-------+ | 266 | ^ | 267 | | | 268 | Peerlist V | 269 | +---------------+ +----+ +-----------+ | 270 | | Tracker |<---->|PEER|<---->| AP |Bottleneck| 271 | +---------------+ +----+ +-----------+ | 272 | ^ ^ ^ ^ | 273 | | | | Low | | 274 | | | |Bandwidth| | 275 | V V V V | 276 | +---+ End-end +---+ +------+ +------+ | 277 | |PC |<------> |PC | |Mobile|<--->|Mobile| | 278 | | | works | | |Phone | ?|Phone | | 279 | +---+ Well +---+ +------+ +------+ | 280 | | 281 | | 282 | | 283 +------------------------------------------------------------+ 285 Figure 1 Mobile Internet communication 287 3.4.2. Limited Bandwidth resource 289 Even if end-to-end communication is ensured, there are still problems 290 for P2P mobile streaming.As shown in Figure1, the following bandwidth 291 is limited and the transmission cost is relatively high: 293 a) between mobile terminals and mobile access nodes; 295 b) between mobile access nodes; 297 c) between mobile network to fixed network. 299 It raises some requirements for PPSP: 301 1) The overhead of PPSP cannot be much. Because PPSP is a signaling 302 protocol, the overhead refers to the ratio of signaling traffic 303 with respect to overall streaming traffic. Different solutions 304 have different overhead. [Computer Networks-Traffic]analyzes four 305 P2P streaming overhead, namely PPLive,PPStream,SOPCast and 306 TVAnts.There is a tradeoff consideration in PPSP. We know that 307 frequent exchange in bitmap may cause a big overhead but it also 308 enables a small peer cache to keep the smooth play of the program. 309 On one hand, the overhead should be minimum to reduce the traffic 310 and increase the efficiency so the bitmap exchange frequency 311 should be small. On the other hand, a mobile terminal has usually 312 small cache size so the bitmap exchange frequency should be large. 313 How to solve the conflict and balance between the cache size and 314 bitmap exchange frequency is a problem PPSP may face with. 316 2) Cross-domain traffic must be reduced. For most mobile Internet 317 domains, their network scale is rather smaller compared with the 318 Tier1 and Tier2 peering networks. Currently peering networks are 319 free from the cross-traffic. However the low-tier ISPs have to pay 320 for dual-directional traffic fee even it's a traffic initiated 321 from higher tier ISPs. It makes mobile Internet provider worse in 322 case P2P streaming applications generate great traffic with a 323 low-cross-domain bandwidth. 325 3.4.3. Other difference 327 Mobility, low battery and capability of mobile terminals make us 328 considering more factors in peer selection to ensure smooth streaming. 329 A new protocol might therefore allow more information to report for 330 trackers to do peer selection. 332 4. Design Issues 334 This section introduces key issues when designing PPSP. 336 4.1. Architecture Choice 338 There are multiple proposed p2p streaming solutions. Some are used in 339 practice and while others are popular in theory. The basic idea of 340 P2P streaming is to partition streaming into chunks and peers are 341 used in relaying chunk transmission. The solutions can be categorized 342 by tree-based and mesh-based [Survey]. The former is ''pushing'' chunks 343 to the audience and the latter is enabling the audience to ''pulls'' 344 the desired chunks from the peers who has. 346 In the tree-based p2p streaming, tree construction and maintenance 347 can be done in either a centralized or a distributed fashion [Survey]. 348 In the mesh-based p2p streaming, no specific topology maintenance is 349 needed. The task is how to locate and retrieve real-time data from 350 multiple sources with different chunks for a streaming. In order to 351 realize this, each peer has to actively locate cache and exchange 352 chunks from other peers by the guidance of the tracker. 354 The biggest challenge in tree-based p2p streaming is two-fold: First, 355 the depth of the tree affects the maximum delay the system has; 356 Second, tree-based streaming still cannot recovery fast enough to 357 handle frequent peer churn. Therefore they are hardly used in 358 practice. On the contrary mesh-based p2p streaming is widely used to 359 overcome these drawbacks for real deployment, like pplive, ppstream, 360 coolstreaming, etc,.. 362 4.2. Integration with existing protocols 364 PPSP will not be a stand-alone protocol. A major advantage of a 365 standard protocol is that we can explicit consider its interactions 366 with other protocols, and design for an integrated system. 368 In particular, we identify that PPSP will interact with the following 369 protocols: RELAOD, ALTO, and RTSP, where P2PSIP, ALTO and MMusic are 370 the most related WGs. 372 4.2.1. Integration with RELOAD 374 RELOAD defined by P2PSIP deals with resource location in end to end 375 commutation. The iterative and recursive routing process in RELOAD is 376 shown in Fig4, which is different from PPSP. That is, the data stored 377 in RELOAD is user profile data and the requester knows exactly what the 378 data is (e.g., the location of Alice@chinamobile.com). While in PPSP, 379 there are many peers storing different data pieces of ''CNN Live''. The 380 only thing a peer must know is the metadata of the movie. A gossip 381 protocol to communicate with other peers is needed to get the real 382 data quickly. 384 +------------------------------------------------+ 385 | +---------------+ | 386 | | Peer | | 387 | +---------------+ | 388 | ^ | ^ | | 389 | 1,2 | |1' 3,4| |3' | 390 | | | | | | 391 | V V V V | 392 | +-------------+ 2' +------------+ | 393 | | Peer |----->| Peer | | 394 | +-------------+ +------------+ | 395 | | 396 +------------------------------------------------+ 398 Figure 2 P2PSIP process 400 The biggest difference between P2PSIP and PPSP lies in their 401 different Search efficiency requirements. PPSP requires retrieving 402 real-time/para real-time data and therefore a tree/mesh topology is 403 built. DHT based topology supported in RELAOD may not be suitable for 404 peer organization. 406 Although P2PSIP doesn't fit for streaming peer organization, it can 407 be deployed in PPSP environment to some extent. 409 First, the topology organization of DHT defined in RELOAD can be used 410 to organize multiple trackers. Due to the large population, some 411 trackers may cooperatively serve a channel/file. Considering the 412 great amount of channels, there are many trackers in practice. 413 Because the search time of which channel/file the tracker stores 414 accounts small percentage in the whole searching procedure, DHT can 415 be used to query for peer list in case of thousand of channels or 416 million of files which are hard to use one tracker. 418 Second, there is a detailed solution for Firewall/NAT transversal in 419 in RELOAD. PPSP faces with the same problem, although not as serious 420 as RELAOD because there are lots of peer candidates with public 421 addresses. But we can definitely reuse RELAOD in case of NAT/Firewall 422 transversal which may occur in mobile environment. 424 4.2.2. Integration with ALTO 426 ALTO is to define a protocol realizing local traffic mostly for P2P 427 applications. The goal of an ALTO solution would be to help peers to 428 find the best sources and the best destinations for media flows they 429 receive and relay. In [draft-marocco-alto-problem-statement-03], the 430 authors mentioned p2p live streaming that can benefit from ALTO 431 service. 433 As we have seen in Section 1, P2P streaming traffic account much on 434 the Internet backbone. PPSP has to consider operator-friendly ways to 435 reduce the cross-backbone traffic in order to control the 436 transmission cost. ALTO is a good candidate to do so. 438 ALTO provides a 3rd party to provide peer locality information based 439 on the premise that the 3rd party has the knowledge of the network 440 topology. In addition there may have extra traffic localization means, 441 e.g., in [draft-zhang-alto-traceroute-00], peers can cluster the 442 nearby peers by simple and lightweight measurements. We can use this 443 mechanism in peer selection to further reduce the traffic. 445 4.2.3. Encapsulating RTSP 447 At a first sight, the function of PPSP protocol is similar to 448 traditional client/server streaming control protocols, RTSP. But in 449 fact RTSP don't involve the problems PPSP has. 451 In RTSP, the focus is to control the streaming, like PLAY, PAUSE; 452 however PPSP focuses on signaling peers for real-time resource 453 discovery, merge and synchronization instead of how to realize 454 streaming control. 456 On the other hand, considering the prevalence of RTSP, it can also be 457 reused in clients without installing PPSP-compatible software to use 458 P2P streaming service. 460 The basic idea in that is to set up a proxy node (e.g., using a cache) 461 which can act as a RTSP server who is actually a peer of PPSP. 463 4.2.4. Edge Device such as Cache Integration 465 As stated in Section 3, if the widely deployed web cache and CDN 466 nodes can be reused in p2p streaming, the video quality, local 467 traffic and some security problems may be better solved.[HTPT] 468 proposes a solution similar to what we propose in section 4.5 to 469 encapsulate and transport them using the HTTP protocol so that they 470 are cacheable. 472 5. Scope of Work 474 We propose to develop an open peer to peer streaming protocol, namely 475 PPSP. The basic task of PPSP is to define a protocol of locating and 476 transmitting real-time data efficiently from multiple sources with 477 different pieces in peer to peer environment. 479 PPSP focuses on how to negotiate with un-preassigned peers for needed 480 chunks. Therefore, PPSP is mainly a signaling protocol and the 481 protocol stack of PPSP is shown in Figure 3. 483 +-----------------------------+ 484 | PPSP Application | 485 |-----------------------------| 486 | PPSP Signaling Protocol | 487 |-----------------------------| 488 | Transport Layer | 489 +-----------------------------+ 491 Figure 3 PPSP Position in Protocol Stack 493 In order to locate real-time data efficiently from multiple sources 494 with different pieces, we have to solve the following problems: 496 1) To standardize the architecture for locating the data efficiently. 498 Tracker-based structure is widely used in current p2p streaming 499 practice. However some tracker-less structures like DHT peer 500 management solutions are also proposed. We need to decide which one 501 is better for p2p streaming; 503 2) To standardize the signaling interaction process. 505 In this part we actually want to standardize client registration 506 process (analogous to TCP 3-way handshake procedure), client 507 information exchange process (analogous to SIP session setup process) 508 and client report process. 510 The current tracker-based means is a two-step searching, i.e., peer 511 reporting to tracker coarse information about it has. Once the 512 tracker is asked, it informs peer of the coarse information; the 513 grain information is achieved by peers exchanging bitmap each other. 514 Some other means, e.g., peer reporting to tracker grain information 515 directly and tracker informs peer of the exact information or DHT 516 based searching, should be evaluated. In each proposal we also need 517 to define the message format in the interactions. 519 3) To discuss how to incorporate node information such as online time, 520 link status, node capability, battery information and some 521 application requirements parameters into the protocol to expand the 522 peer selection. 524 In this part, we actually want to standardize PPSP message headers 525 (analogous to IP header definition) and PPSP metadata format 526 (analogous to SIP header definition). 528 6. Security Considerations 530 PPSP has a similar assumption in peer privacy as P2PSIP, i.e., all 531 participants in the system are issued unique identities and 532 credentials through some mechanism not in the scope of this working 533 group, such as a centralized server. Hence the WG will not attempt a 534 solution to these issues for P2P streaming networks in general. 535 However PPSP has some unique privacy issue different from P2PSIP: 537 1) The content published by peers may not be checked by centralized 538 certificating server because of the high amount. Therefore P2P 539 streaming network faces with more serious malicious content 540 distribution danger than P2PSIP. 542 2) Content Pollution is a phenomenon P2PSIP may not meet with. But 543 these is a common problem faced by P2P streaming and file sharing. 544 It's recorded that there are about 50% of the content is polluted in 545 file sharing applications. Although it's not as serious as file 546 sharing content pollution, it's still a big issue P2P streaming 547 applications face with. 549 3) Because there is a tracker server who is critical to the P2P 550 streaming systems. It has more probability to launch attacks to the 551 tracker. 553 PPSP may include some security mechanisms to prevent malicious nodes 554 to pollute or launch attacks to the tracker. Security issues in PPSP 555 need to be further investigated. 557 7. Acknowledgments 559 Funding for the RFC Editor function is provided by the IETF 560 Administrative Support Activity (IASA). 562 8. References 564 8.1.Normative References 566 [Cisco] Approaching the Zettabyte Era by Cisco. 568 [PPLive] www.pplive.com 570 [PPStream] www.ppstream.com 572 [UUSee] www.uusee.com 574 [youtube] www.youtube.com 576 [tudou] www.tudou.com 578 [CNN] www.cnn.com 580 [Octoshape] www.octoshape.com 582 [ATT]http://mobile.sooyuu.com/Article/content/200905/217315094629281_ 583 1.shtml 585 [Sigcomm:P2P streaming] Challenges, Design and Analysis of a Large- 586 scale P2P-VoD System,Yan Huang et al, Sigcomm08. 588 [draft-marocco-alto-problem-statement-03], Application-Layer Traffic 589 Optimization (ALTO) Problem Statement, E. Marocco et al, draft- 590 marocco-alto-problem-statement-03 592 [Pando]www.pando.com 594 [CoolStreaming] CoolStreaming/DONet: A Data-Driven Overlay Network 595 for Efficient Live Media Streaming, Xinyan Zhang et al, 597 [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen 598 et al, 600 [draft-zhang-ppsp-protocol-comparison-measurement- 601 00]www.ietf.org/internet-drafts/draft-zhang-ppsp-protocol-comparison- 602 measurement-00.txt 604 [GENI] www.geni.net 606 [FIND]www.nets-find.net 608 [draft-zhang-ppsp-dsn-introduction-00]www.ietf.org/internet- 609 draft/draft-zhang-ppsp-dsn-introduction-00.txt 611 [MobileTV] MobileTV,Turning in or switching off, Arthur D. Little 613 [Computer Networks:Traffic] Traffic analysis of peer-to-peer IPTV 614 communities, Thomas Silverston et al, Computer Networks, 53 (2009) 615 470--484 617 [Survey]A survey on peer-to-peer video streaming systems Yong Liu et 618 al, Peer-to-Peer Netw Appl (2008) 1:18- -28,Springer. 620 [draft-zhang-alto-traceroute-00] www.ietf.org/internet-draft/draft- 621 zhang-alto-traceroute-00.txt 623 8.2.Informative References 625 Author's Addresses 627 Yunfei Zhang 629 China Mobile Communication Corporation 631 zhangyunfei@chinamobile.com 633 Ning Zong 635 Huawei Technologies Co., Ltd. 637 zongning@huawei.com 639 Gonzalo Camarillo 641 Ericsson 643 Gonzalo.Camarillo@ericsson.com 645 James Seng 647 PPLive 649 james.seng@pplive.com 651 Richard Yang 653 Yale University 655 yry@cs.yale.edu