idnits 2.17.1 draft-zhang-ppsp-problem-statement-03.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 10 instances of too long lines in the document, the longest one being 6 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 91, but not defined == Missing Reference: 'PPstream' is mentioned on line 105, but not defined == Missing Reference: 'P2PStreamSurvey' is mentioned on line 128, but not defined == Missing Reference: 'Pando' is mentioned on line 205, but not defined == Missing Reference: 'Coolstreaming' is mentioned on line 206, but not defined == Missing Reference: 'HTPT' is mentioned on line 489, but not defined == Missing Reference: 'FIND' is mentioned on line 252, but not defined == Missing Reference: 'Survey' is mentioned on line 369, but not defined == Unused Reference: 'PPStream' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'Octoshape' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'CoolStreaming' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'HPTP' is defined on line 620, 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 Plive 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-03.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 the problems related to PPSP and 54 outlines considerations that have to be taken in account when 55 arriving at equitable solutions. 57 Table of Contents 59 1. Introduction..................................................4 60 1.1. Research or Engineering..................................4 61 1.2. Objective and outline....................................5 62 2. Definitions...................................................6 63 3. Problem Statement Scope.......................................6 64 3.1. Proprietary protocols and an open PPSP...................7 65 3.2. Integrating cache and CDN into P2P streaming.............7 66 3.3. Integrating existing protocols into P2P streaming........7 67 3.4. Mobility and wireless issue..............................8 68 3.4.1. End to end communication is harder..................8 69 3.4.2. Limited Bandwidth resource..........................9 70 3.4.3. Other difference...................................10 71 4. Design Issues................................................11 72 4.1. Architecture Choice.....................................11 73 4.2. Integration with existing protocols.....................11 74 4.2.1. Integration with RELOAD............................11 75 4.2.2. Integration with ALTO..............................13 76 4.2.3. Encapsulating RTSP.................................13 77 4.2.4. Edge Device such as Cache Integration..............13 78 5. Scope of Work................................................15 79 6. Security Considerations......................................17 80 7. Acknowledgments..............................................17 81 8. References...................................................17 83 1. Introduction 85 Streaming traffic is among the fastest growing traffic on the 86 Internet. In a recent white paper, Cisco predicts that by 2012, 90% 87 of all Internet traffic will be video [Cisco]. 89 There are two basic architectures for delivering streaming traffic on 90 the global Internet: the client-server paradigm and the peer to peer 91 (P2P) paradigm [P2PStreamingSurvey]. A particular advantage of the 92 P2P paradigm over the client-server paradigm is its scalability. As 93 an example, PPLive [PPLive], one of the largest P2P streaming vendors, 94 is able to distribute large-scale, live streaming programs such as 95 the CCTV Spring Festival Gala to more than 2 million users with only 96 a handful of servers. CNN[CNN] reported that P2P streaming by 97 Octoshape played a major role in its distribution of the historical 98 inauguration address of President Obama. It is well demonstrated in 99 practice that P2P streaming can deliver videos encoded at a rate of 100 about 400 Kbps, in the presence of rapid user joins/leaves, with 101 positive user experiences. 103 With the preceding technical advantages, P2P streaming is seeing 104 rapid deployment. Large P2P streaming applications such as PPLive 105 [PPLive], PPstream [PPstream] and UUSee [UUSee] each has a user base 106 exceeding 100 millions. P2P streaming traffic is becoming a major 107 type of Internet traffic in some Internet networks. For example, 108 according to the statistics of a major Chinese ISP, the traffic 109 generated by P2P streaming applications exceeded 50% of the total 110 backbone traffic during peak time in 2008. There were reports that 111 major video distributors such as Youtube [youtube] and tudou [tudou] 112 are conducting trials of using P2P streaming as a component of their 113 delivery infrastructures. 115 Given the increasing integration of P2P streaming into the global 116 content delivery infrastructure, the lacking of an open, standard P2P 117 streaming protocol becomes a major missing component in the Internet 118 protocol stack. Multiple, similar but proprietary P2P streaming 119 protocols result in repetitious development efforts and lock-in 120 effects. More importantly, it leads to substantial difficulties when 121 integrating P2P streaming as an integral component of a global 122 content delivery infrastructure. For example, proprietary P2P 123 streaming protocols do not integrate well with existing cache and 124 other edge infrastructures. 126 1.1. Research or Engineering 128 As [P2PStreamSurvey] identifies, there exist multiple proprietary P2P 129 streaming systems including PPLive, PPstream, UUsee, Pando, abacast, 130 and Coolstreaming. A natural question to ask is whether the 131 development of P2P streaming is mature and ready for standardization. 132 We admit that P2P streaming will continue to improve and evolve. 133 However, our investigation shows that existing P2P streaming systems 134 are largely converging, sharing similar architecture and signaling 135 protocols [draft-zhang-ppsp-protocol-comparison-measurement-00]. The 136 competition of P2P streaming vendors become increasingly on contents. 138 1.2. Objective and outline 140 Our objective is to develop a standard P2P streaming protocol that 141 can operate in both fixed and mobile Internet. The protocol will 142 serve as an enabling technology, building on the development 143 experiences of existing P2P streaming protocols. It will integrate 144 with IETF efforts on distributed resource location, traffic 145 localization, and streaming control mechanisms. It allows effective 146 integration with edge infrastructures such as cache and mobile edge 147 equipment. 149 This document provides a problem statement for designing PPSP. The 150 rest of the document is organized as follows. In Section 2, we 151 introduce terminologies. In Section 3, we identify the current 152 problems in providing a scalable and economical streaming system.In 153 Section 4, we describe the main issues to consider when designing 154 PPSP. In Section 5, we outline the main scope of work. 156 2. Definitions 158 The following terms have special meaning in the definition of thePeer 159 to Peer Streaming Protocol (PPSP) problem. 161 Tracker: A dedicated server who is in charge of maintaining peer list 162 and replying peer request for peer selection. 164 Peer: A peer refers to a participant in a P2P streaming system who 165 acts both as "client" and "server". 167 Chunk: A chunk is a basic unit of partitioned streaming, which is 168 used for the purpose of storage and advertising to neighbors what 169 parts of a movie a peer holds [Sigcomm:P2P streaming]. 171 Bitmap: Bitmap is a table indicating which chunks a peer has. 173 Peering networks: Two directly connected Internet Service Providers. 174 Apart from infrastructure and operational costs, peering traffic is 175 usually free, within the contract of a peering a greement [draft- 176 marocco-alto-problem-statement-03]. 178 3. Problem Statement Scope 180 We perceive a number of problems related to scalable and economical 181 streaming on the Internet. The major issues are the following: 183 1) The difficulty of an open PPSP due to the existence of many 184 proprietary and non-interoperable protocols in current p2p 185 streaming applications; 187 2) The difficulty of integrating current edge equipments such as 188 cache and content distribution network (CDN) nodes into P2P 189 streaming; 191 3) The difficulty of integrating related protocols into P2P 192 streaming, like RELOAD,ALTO,RTSP, which is beyond current P2P 193 streaming usage; 195 4) The lack of a standard solution for scalable and economical 196 streaming signaling interaction suitable both for fixed internet 197 and mobile Internet; a related problem is that the difficulty of 198 deploying p2p streaming in mobile Internet; 200 The subsections below discuss these problems in more detail. 202 3.1. Proprietary protocols and an open PPSP 204 Currently there exist some P2P streaming systems like PPLive, 205 PPstream, UUsee, Pando[Pando] and 206 Coolstreaming[Coolstreaming].Although using similar system 207 architecture as well as signaling interaction processes[draft-zhang- 208 ppsp-protocol-comparison-measurement-00], due to their proprietary 209 protocols, it's hard to develop an open PPSP protocol without 210 checking all the typical P2P streaming systems, identifying the key 211 issues and considering all the requirements. 213 3.2. Integrating cache and CDN into P2P streaming 215 To make P2P streaming stable and traffic local enough, cache and 216 other edge infrastructure is a very promising means [draft-marocco- 217 alto-problem-statement-03]. 218 However there are a few obstacles in deploying P2P caches [HTPT]: 219 firstly, P2P caching systems are likely to be very complicated. 220 Unlike web traffic standardized in using HTTP transport through few 221 dedicated ports like 80, there is no a standard P2P protocol and 222 every P2P protocol uses its own port. Therefore, P2P caching systems 223 are forced to take an ad hoc approach by enumerating and handling 224 every P2P protocol. Another drawback of this ad hoc approach is the 225 requirement of regular update of the P2P cache engines to handle 226 newly emerged popular P2P protocols. Secondly, extra, possibly huge, 227 investment is required for the equipment and facility purchase and 228 also the administrative cost. 229 If we can utilize the existing cache and other edge equipments like 230 CDN nodes, the cost can be heavily reduced. Meanwhile because it's 231 widely used, the performance of P2P streaming can increase much. 232 Therefore how to utilize the edge infrastructure is a big issue. 233 Current web cache or other widely deployed edge equipments like CDN 234 doesn't support P2P streaming yet[HTPT]. 236 3.3. Integrating existing protocols into P2P streaming 238 There are several protocols related to p2p streaming having been or 239 being defined in IETF, including RELAOD,ALTO,RTSP,etc.., where 240 P2PSIP,ALTO and MMusic are most related WGs. Unfortunately there is 241 no one protocol above considered by current P2P streaming 242 applications. 244 We claim that PPSP is not a stand-alone protocol. It could and should 245 integrate with the existing related protocols to the largest extent. 247 We analyze several protocols PPSP may relate to in detail in section4. 249 3.4. Mobility and wireless issue 251 Mobility and wireless becomes a very important feather to support in 252 future internet [GENI],[FIND]. Some operators have also started 253 research projects on mobile and wireless Internet. For example, China 254 Mobile came out with its DSN (distributed services network) strategy 255 last year to build its mobile Internet [draft-zhang-ppsp-dsn- 256 introduction-00]. 258 Along with the introduction of mobile and wireless characteristics 259 into Internet, mobile streaming will become more and more 260 popular[MobileTV].In Korea the mobilTV subscriber is 17 million 261 accounting one third of the mobile subscriber. In Italy there are 1 262 million mobileTV users. In the period of Beijing Olympic games, there 263 are more than 1 million usage of China mobile's mobileTV. 265 Most of current mobileTV are developed in client/server model. It's a 266 natural idea to increase its scalability and decrease the cost by 267 deploying P2P mobile streaming. 269 However there are a lot of differences in mobile/wireless Internet 270 compared with fixed Internet environment. This makes it hard to copy 271 current P2P streaming protocol in fixed Internet environment. 273 3.4.1. End to end communication is harder 275 Unlike fixed Internet, it's difficult to realize end-to-end 276 communication in mobile Internet. Mobile terminals cannot connect 277 with each other directly. The connection must be set up by 278 mobile/wireless access nodes. Therefore mobile terminals are hard to 279 become peers without the cooperation of mobile/wireless access 280 equipments. It's obviously a heavy burden for the mobile/wireless 281 access points. 283 +------------------------------------------------------------+ 284 | | 285 | +-------+ | 286 | | Cache | | 287 | +-------+ | 288 | ^ | 289 | | | 290 | Peerlist V | 291 | +---------------+ +----+ +-----------+ | 292 | | Tracker |<---->|PEER|<---->| AP |Bottleneck| 293 | +---------------+ +----+ +-----------+ | 294 | ^ ^ ^ ^ | 295 | | | | Low | | 296 | | | |Bandwidth| | 297 | V V V V | 298 | +---+ End-end +---+ +------+ +------+ | 299 | |PC |<------> |PC | |Mobile|<--->|Mobile| | 300 | | | works | | |Phone | X |Phone | | 301 | +---+ Well +---+ +------+ +------+ | 302 | | 303 | | 304 | | 305 +------------------------------------------------------------+ 307 Figure 1 Mobile Internet communication 309 3.4.2. Limited Bandwidth resource 311 Even if end-to-end communication is ensured, there are still problems 312 for P2P mobile streaming.As shown in Figure1, the following bandwidth 313 is limited and the transmission cost is relatively high: 315 a) between mobile terminals and mobile access nodes; 317 b) between mobile access nodes; 319 c) between mobile network to fixed network. 321 It raises some requirements for PPSP: 323 1) The overhead of PPSP cannot be much. Because PPSP is a signaling 324 protocol, the overhead refers to the ratio of signaling traffic 325 with respect to overall streaming traffic. Different solutions 326 have different overhead. [Computer Networks-Traffic]analyzes four 327 P2P streaming overhead, namely PPLive,PPStream,SOPCast and 328 TVAnts.There is a tradeoff consideration in PPSP. We know that 329 frequent exchange in bitmap may cause a big overhead but it also 330 enables a small peer cache to keep the smooth play of the program. 331 On one hand, the overhead should be minimum to reduce the traffic 332 and increase the efficiency so the bitmap exchange frequency 333 should be small. On the other hand, a mobile terminal has usually 334 small cache size so the bitmap exchange frequency should be large. 335 How to solve the conflict and balance between the cache size and 336 bitmap exchange frequency is a problem PPSP may face with. 338 2) Cross-domain traffic must be reduced. For most mobile Internet 339 domains, their network scale is rather smaller compared with the 340 Tier1 and Tier2 peering networks. Currently peering networks are 341 free from the cross-traffic. However the low-tier ISPs have to pay 342 for dual-directional traffic fee even it's a traffic initiated 343 from higher tier ISPs. It makes mobile Internet provider worse in 344 case P2P streaming applications generate great traffic with a 345 low-cross-domain bandwidth. 347 3.4.3. Other difference 349 Mobility, low battery and capability of mobile terminals make us 350 considering more factors in peer selection to ensure smooth streaming. 351 A new protocol might therefore allow more information to report for 352 trackers to do peer selection. 354 4. Design Issues 356 This section introduces key issues when designing PPSP. 358 4.1. Architecture Choice 360 There are multiple proposed p2p streaming solutions. Some are used in 361 practice and while others are popular in theory. The basic idea of 362 P2P streaming is to partition streaming into chunks and peers are 363 used in relaying chunk transmission. The solutions can be categorized 364 by tree-based and mesh-based [Survey]. The former is "pushing" chunks 365 to the audience and the latter is enabling the audience to "pulls" 366 the desired chunks from the peers who has. 368 In the tree-based p2p streaming, tree construction and maintenance 369 can be done in either a centralized or a distributed fashion [Survey]. 370 In the mesh-based p2p streaming, no specific topology maintenance is 371 needed. The task is how to locate and retrieve real-time data from 372 multiple sources with different chunks for a streaming. In order to 373 realize this, each peer has to actively locate cache and exchange 374 chunks from other peers by the guidance of the tracker. 376 The biggest challenge in tree-based p2p streaming is two-fold: First, 377 the depth of the tree affects the maximum delay the system has; 378 Second, tree-based streaming still cannot recovery fast enough to 379 handle frequent peer churn. Therefore they are hardly used in 380 practice. On the contrary mesh-based p2p streaming is widely used to 381 overcome these drawbacks for real deployment, like pplive, ppstream, 382 coolstreaming, etc,.. 384 4.2. Integration with existing protocols 386 PPSP will not be a stand-alone protocol. A major advantage of a 387 standard protocol is that we can explicit consider its interactions 388 with other protocols, and design for an integrated system. 390 In particular, we identify that PPSP will interact with the following 391 protocols: RELAOD, ALTO, and RTSP, where P2PSIP, ALTO and MMusic are 392 the most related WGs. 394 4.2.1. Integration with RELOAD 396 RELOAD defined by P2PSIP deals with resource location in end to end 397 commutation. The iterative and recursive routing process in RELOAD is 398 shown in Fig4, which is different from PPSP. That is, the data stored 399 in RELOAD is user profile data and the requester knows exactly what 400 the data is (e.g., the location of Alice@chinamobile.com). While in 401 PPSP, there are many peers storing different data pieces of ''CNN 402 Live''. The only thing a peer must know is the metadata of the movie. 403 A gossip protocol to communicate with other peers is needed to get 404 the real data quickly. 406 +------------------------------------------------+ 407 | +---------------+ | 408 | | Peer | | 409 | +---------------+ | 410 | ^ | ^ | | 411 | 1,2 | |1' 3,4| |3' | 412 | | | | | | 413 | V V V V | 414 | +-------------+ 2' +------------+ | 415 | | Peer |----->| Peer | | 416 | +-------------+ +------------+ | 417 | | 418 +------------------------------------------------+ 420 Figure 2 P2PSIP process 422 The biggest difference between P2PSIP and PPSP lies in their 423 different Search efficiency requirements. PPSP requires retrieving 424 real-time/para real-time data and therefore a tree/mesh topology is 425 built. DHT based topology supported in RELAOD may not be suitable for 426 peer organization. 428 Although P2PSIP doesn't fit for streaming peer organization, it can 429 be deployed in PPSP environment to some extent. 431 First, the topology organization of DHT defined in RELOAD can be used 432 to organize multiple trackers. Due to the large population, some 433 trackers may cooperatively serve a channel/file. Considering the 434 great amount of channels, there are many trackers in practice. 435 Because the search time of which channel/file the tracker stores 436 accounts small percentage in the whole searching procedure, DHT can 437 be used to query for peer list in case of thousand of channels or 438 million of files which are hard to use one tracker. 440 Second, there is a detailed solution for Firewall/NAT transversal in 441 in RELOAD. PPSP faces with the same problem, although not as serious 442 as RELAOD because there are lots of peer candidates with public 443 addresses. But we can definitely reuse RELAOD in case of NAT/Firewall 444 transversal which may occur in mobile environment. 446 4.2.2. Integration with ALTO 448 ALTO is to define a protocol realizing local traffic mostly for P2P 449 applications. The goal of an ALTO solution would be to help peers to 450 find the best sources and the best destinations for media flows they 451 receive and relay. In [draft-marocco-alto-problem-statement-03], the 452 authors mentioned p2p live streaming that can benefit from ALTO 453 service. 455 As we have seen in Section 1, P2P streaming traffic account much on 456 the Internet backbone. PPSP has to consider operator-friendly ways to 457 reduce the cross-backbone traffic in order to control the 458 transmission cost. ALTO is a good candidate to do so. 460 ALTO provides a 3rd party to provide peer locality information based 461 on the premise that the 3rd party has the knowledge of the network 462 topology. In addition there may have extra traffic localization means, 463 e.g., in [draft-zhang-alto-traceroute-00], peers can cluster the 464 nearby peers by simple and lightweight measurements. We can use this 465 mechanism in peer selection to further reduce the traffic. 467 4.2.3. Encapsulating RTSP 469 At a first sight, the function of PPSP protocol is similar to 470 traditional client/server streaming control protocols, RTSP. But in 471 fact RTSP don't involve the problems PPSP has. 473 In RTSP, the focus is to control the streaming, like PLAY, PAUSE; 474 however PPSP focuses on signaling peers for real-time resource 475 discovery, merge and synchronization instead of how to realize 476 streaming control. 478 On the other hand, considering the prevalence of RTSP, it can also be 479 reused in clients without installing PPSP-compatible software to use 480 P2P streaming service. 482 The basic idea in that is to set up a proxy node (e.g., using a cache) 483 which can act as a RTSP server who is actually a peer of PPSP. 485 4.2.4. Edge Device such as Cache Integration 487 As stated in Section 3, if the widely deployed web cache and CDN 488 nodes can be reused in p2p streaming, the video quality, local 489 traffic and some security problems may be better solved.[HTPT] 490 proposes a solution similar to what we propose in section 4.5 to 491 encapsulate and transport them using the HTTP protocol so that they 492 are cacheable. 494 5. Scope of Work 496 We propose to develop an open peer to peer streaming protocol, namely 497 PPSP. The basic task of PPSP is to define a protocol of locating and 498 transmitting real-time data efficiently from multiple sources with 499 different pieces in peer to peer environment. 501 PPSP focuses on how to negotiate with un-preassigned peers for needed 502 chunks. Therefore, PPSP is mainly a signaling protocol and the 503 protocol stack of PPSP is shown in Figure 3. 505 +-----------------------------+ 506 | PPSP Application | 507 |-----------------------------| 508 | PPSP Signaling Protocol | 509 |-----------------------------| 510 | Transport Layer | 511 +-----------------------------+ 513 Figure 3 PPSP Position in Protocol Stack 515 In order to locate real-time data efficiently from multiple sources 516 with different pieces, we have to solve the following problems: 518 1) To standardize the architecture for locating the data efficiently. 520 Tracker-based structure is widely used in current p2p streaming 521 practice. However some tracker-less structures like DHT peer 522 management solutions are also proposed. We need to decide which one 523 is better for p2p streaming; 525 2) To standardize the signaling interaction process. 527 In this part we actually want to standardize client registration 528 process (analogous to TCP 3-way handshake procedure), client 529 information exchange process (analogous to SIP session setup process) 530 and client report process. 532 The current tracker-based means is a two-step searching, i.e., peer 533 reporting to tracker coarse information about it has. Once the 534 tracker is asked, it informs peer of the coarse information; the 535 grain information is achieved by peers exchanging bitmap each other. 536 Some other means, e.g., peer reporting to tracker grain information 537 directly and tracker informs peer of the exact information or DHT 538 based searching, should be evaluated. In each proposal we also need 539 to define the message format in the interactions. 541 3) To discuss how to incorporate node information such as online time, 542 link status, node capability, battery information and some 543 application requirements parameters into the protocol to expand the 544 peer selection. 546 In this part, we actually want to standardize PPSP message headers 547 (analogous to IP header definition) and PPSP metadata format 548 (analogous to SIP header definition). 550 6. Security Considerations 552 PPSP has a similar assumption in peer privacy as P2PSIP, i.e., all 553 participants in the system are issued unique identities and 554 credentials through some mechanism not in the scope of this working 555 group, such as a centralized server. Hence the WG will not attempt a 556 solution to these issues for P2P streaming networks in general. 557 However PPSP has some unique privacy issue different from P2PSIP: 559 1) The content published by peers may not be checked by centralized 560 certificating server because of the high amount. Therefore P2P 561 streaming network faces with more serious malicious content 562 distribution danger than P2PSIP. 564 2) Content Pollution is a phenomenon P2PSIP may not meet with. But 565 these is a common problem faced by P2P streaming and file sharing. 566 It's recorded that there are about 50% of the content is polluted in 567 file sharing applications. Although it's not as serious as file 568 sharing content pollution, it's still a big issue P2P streaming 569 applications face with. 571 3) Because there is a tracker server who is critical to the P2P 572 streaming systems. It has more probability to launch attacks to the 573 tracker. 575 PPSP may include some security mechanisms to prevent malicious nodes 576 to pollute or launch attacks to the tracker. Security issues in PPSP 577 need to be further investigated. 579 7. Acknowledgments 581 We have to acknowledge many people. For the record: D.Bryan from SIPeerior; 582 E.Marocco from TI;V.Gurbani from AT&T;R.Even from Huawei;H.Zhang from NEC 583 Labs,USA;C.Schmidt and L.Xiao from NSN;C.Williams from ZTE;V.Pasual 584 from Tekelec; X.Zhang from PPlive; H.Deng from China Mobile;and J. 585 Lei from Univ. of Goettingen. 587 8. References 589 [Cisco] Approaching the Zettabyte Era by Cisco. 591 [PPLive] www.pplive.com 593 [PPStream] www.ppstream.com 595 [UUSee] www.uusee.com 597 [youtube] www.youtube.com 599 [tudou] www.tudou.com 601 [CNN] www.cnn.com 603 [Octoshape] www.octoshape.com 605 [ATT]http://mobile.sooyuu.com/Article/content/200905/217315094629281_ 606 1.shtml 608 [Sigcomm:P2P streaming]Challenges, Design and Analysis of a Large- 609 scale P2P-VoD System,Yan Huang et al, Sigcomm08. 611 [draft-marocco-alto-problem-statement-03], Application-Layer Traffic 612 Optimization (ALTO) Problem Statement, E. Marocco et al, draft- 613 marocco-alto-problem-statement-03 615 [Pando]www.pando.com 617 [CoolStreaming] CoolStreaming/DONet: A Data-Driven Overlay Network 618 for Efficient Live Media Streaming, Xinyan Zhang et al, 620 [HPTP] HPTP: Relieving the Tension between ISPs and P2P, Guobin Shen 621 et al, 623 [draft-zhang-ppsp-protocol-comparison-measurement- 624 00]www.ietf.org/internet-drafts/draft-zhang-ppsp-protocol-comparison- 625 measurement-00.txt 627 [GENI] www.geni.net 629 [FIND]www.nets-find.net 631 [draft-zhang-ppsp-dsn-introduction-00]www.ietf.org/internet- 632 draft/draft-zhang-ppsp-dsn-introduction-00.txt 634 [MobileTV] MobileTV,Turning in or switching off, Arthur D. Little 636 [Computer Networks:Traffic] Traffic analysis of peer-to-peer IPTV 637 communities, Thomas Silverston et al, Computer Networks, 53 (2009) 638 470-484 640 [Survey]A survey on peer-to-peer video streaming systems Yong Liu et 641 al, Peer-to-Peer Netw Appl (2008) 1:18-28,Springer. 643 [draft-zhang-alto-traceroute-00] www.ietf.org/internet-draft/draft- 644 zhang-alto-traceroute-00.txt 646 Author's Addresses 648 Yunfei Zhang 650 China Mobile Communication Corporation 652 zhangyunfei@chinamobile.com 654 Ning Zong 656 Huawei Technologies Co., Ltd. 658 zongning@huawei.com 660 Gonzalo Camarillo 662 Ericsson 664 Gonzalo.Camarillo@ericsson.com 666 James Seng 668 PPLive 670 james.seng@pplive.com 672 Richard Yang 674 Yale University 676 yry@cs.yale.edu