idnits 2.17.1 draft-gu-ppsp-survey-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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.) ** There are 17 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 (October 25, 2010) is 4931 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: 'P2PIPTV-measuring' is mentioned on line 488, but not defined == Missing Reference: 'TM' is mentioned on line 603, but not defined == Unused Reference: 'PPLive' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'PPStream' is defined on line 726, but no explicit reference was found in the text == Unused Reference: 'CNN' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'OctoshapeWeb' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'Joost-Experiment' is defined on line 734, but no explicit reference was found in the text == Unused Reference: 'Conviva' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'Survey' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'P2PStreamingSurvey' is defined on line 761, but no explicit reference was found in the text == Unused Reference: 'Challenge' is defined on line 767, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPSP Y. Gu 3 Internet-Draft N. Zong 4 Intended status: Standards Track Huawei 5 Expires: April 28, 2011 Hui. Zhang 6 NEC Labs America. 7 Yunfei. Zhang 8 China Mobile 9 J. Lei 10 University of Goettingen 11 Gonzalo. Camarillo 12 Ericsson 13 Yong. Liu 14 Polytechnic University 15 October 25, 2010 17 Survey of P2P Streaming Applications 18 draft-gu-ppsp-survey-02 20 Abstract 22 This document presents a survey of popular Peer-to-Peer streaming 23 applications on the Internet. We focus on the Architecture and Peer 24 Protocol/Tracker Signaling Protocol description in the presentation, 25 and study a selection of well-known P2P streaming systems, including 26 Joost, PPlive, andother popular existing systems. Through the 27 survey, we summarize a common P2P streaming process model and the 28 correspondent signaling process for P2P Streaming Protocol 29 standardization. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 28, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 3 66 3. Survey of P2P streaming system . . . . . . . . . . . . . . . . 4 67 3.1. Mesh-based P2P streaming systems . . . . . . . . . . . . . 4 68 3.1.1. Joost . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1.2. Octoshape . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1.3. PPLive . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.1.4. Zattoo . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1.5. PPStream . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.1.6. SopCast . . . . . . . . . . . . . . . . . . . . . . . 11 74 3.1.7. TVants . . . . . . . . . . . . . . . . . . . . . . . . 11 75 3.2. Tree-based P2P streaming systems . . . . . . . . . . . . . 12 76 3.2.1. PeerCast . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.2.2. Conviva . . . . . . . . . . . . . . . . . . . . . . . 14 78 4. A common P2P Streaming Process Model . . . . . . . . . . . . . 15 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 81 7. Informative References . . . . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 Toward standardizing the signaling protocols used in today's Peer-to- 87 Peer (P2P) streaming applications, we surveyed several popular P2P 88 streaming systems regarding their architectures and signaling 89 protocols between peers, as well as, between peers and trackers. The 90 studied P2P streaming systems, running worldwide or domestically, 91 include such as PPLive, Joost, Cybersky-TV, and Octoshape. This 92 document does not intend to cover all design options of P2P streaming 93 applications. Instead, we choose a representative set of 94 applications and focus on the respective signaling characteristics of 95 each kind. Through the survey, we generalize a common streaming 96 process model from those P2P streaming systems, and summarize the 97 companion signaling process as the base for P2P Streaming Protocol 98 (PPSP) standardization. 100 2. Terminologies and concepts 102 Chunk: A chunk is a basic unit of partitioned streaming media, which 103 is used by a peer for the purpose of storage, advertisement and 104 exchange among peers [Sigcomm:P2P streaming]. 106 Content Distribution Network (CDN) node: A CDN node refers to a 107 network entity that usually is deployed at the network edge to store 108 content provided by the original servers, and serves content to the 109 clients located nearby topologically. 111 Live streaming: The scenario where all clients receive streaming 112 content for the same ongoing event. The lags between the play points 113 of the clients and that of the streaming source are small.. 115 P2P cache: A P2P cache refers to a network entity that caches P2P 116 traffic in the network, and either transparently or explicitly 117 distributes content to other peers. 119 P2P streaming protocols: P2P streaming protocols refer to multiple 120 protocols such as streaming control, resource discovery, streaming 121 data transport, etc. which are needed to build a P2P streaming 122 system. 124 Peer/PPSP peer: A peer/PPSP peer refers to a participant in a P2P 125 streaming system. The participant not only receives streaming 126 content, but also stores and uploads streaming content to other 127 participants. 129 PPSP protocols: PPSP protocols refer to the key signaling protocols 130 among various P2P streaming system components, including the tracker 131 and peers. 133 Swarm: A swarm refers to a group of clients (i.e. peers) sharing the 134 same content (e.g. video/audio program, digital file, etc) at a given 135 time. 137 Tracker/PPSP tracker: A tracker/PPSP tracker refers to a directory 138 service which maintains the lists of peers/PPSP peers storing chunks 139 for a specific channel or streaming file, and answers queries from 140 peers/PPSP peers. 142 Video-on-demand (VoD): A kind of application that allows users to 143 select and watch video content on demand 145 3. Survey of P2P streaming system 147 In this section, we summarize some existing P2P streaming systems. 148 The construction techniques used in these systems can be largely 149 classified into two categories: tree-based and mesh-based structures. 151 Tree-based structure: Group members self-organize into a tree 152 structure, based on which group management and data delivery is 153 performed. Such structure has small maintenance cost and good 154 scalability and can be easily implemented. However, it may result in 155 low bandwidth usage and less reliability. 157 Mesh-based structure: In contrast to tree-based structure, a mesh 158 uses multiple links between any two nodes. Thus, the reliability of 159 data transmission is relatively high. Nevertheless, the cost of 160 maintaining such mesh is much larger than that of a tree. 162 3.1. Mesh-based P2P streaming systems 164 3.1.1. Joost 166 Joost announced to give up P2P technology on its desktop version last 167 year, though it introduced a flash version for browsers and iPhone 168 application. The key reason why Joost shut down its desktop version 169 is probably the legal issues of provided media content. However, as 170 one of the most popular P2P VoD application in the past years, it's 171 worthwhile to understand how Joost works. The peer management and 172 data transmission in Joost mainly relies on mesh-based structure. 174 The three key components of Joost are servers, super nodes and peers. 175 There are five types of servers: Tracker server, Version server, 176 Backend server, Content server and Graphics server. The architecture 177 of Joost system is shown in Figure 1. 179 First, we introduce the functionalities of Joost's key components 180 through three basic phases. Then we will discuss the Peer protocol 181 and Tracker protocol of Joost. 183 Installation: Backend server is involved in the installation phase. 184 Backend server provides peer with an initial channel list in a SQLite 185 file. No other parameters, such as local cache, node ID, or 186 listening port, are configured in this file. 188 Bootstrapping: In case of a newcomer, Tracker server provides several 189 super node addresses and possibly some content server addresses. 190 Then the peer connects Version server for the latest software 191 version. Later, the peer starts to connect some super nodes to 192 obtain the list of other available peers and begins streaming video 193 contents. Different from Skype [skype], super nodes in Joost only 194 deal with control and peer management traffic. They do not relay/ 195 forward any media data. 197 Channel switching: Super nodes are responsible for redirecting 198 clients to content server or peers. 200 Peers communicate with servers over HTTP/HTTPs and with super nodes/ 201 other peers over UDP. 203 Tracker Protocol: Because super nodes here are responsible for 204 providing the peerlist/content servers to peers, protocol used 205 between tracker server and peers is rather simple. Peers get the 206 addresses of super nodes and content servers from Tracker Server over 207 HTTP. After that, Tracker sever will not appear in any stage, e.g. 208 channel switching, VoD interaction. In fact, the protocol spoken 209 between peers and super nodes is more like what we normally called 210 "Tracker Protocol". It enables super nodes to check peer status, 211 maintain peer lists for several, if not all, channels. It provides 212 peer list/content servers to peers. Thus, in the rest of this 213 section, when we mention Tracker Protocol, we mean the one used 214 between peers and super nodes. 216 Peers will communicate with super nodes in some scenarios using 217 Tracker Protocol. 219 1. When a peer starts Joost software, after the installation and 220 bootstrapping, the peer will communicate with one or several super 221 nodes to get a list of available peers/content servers. 223 2. For on-demand video functions, super nodes periodically exchange 224 small UDP packets for peer management purpose. 226 3. When switching between channels, peers contact super nodes and 227 the latter help the peers find available peers to fetch the requested 228 media data. 230 Peer Protocol: The following investigations are mainly motivated from 231 [Joost- experiment ], in which a data-driven reverse-engineer 232 experiments are performed. We omitted the analysis process and 233 directly show the conclusion. Media data in Joost is split into 234 chunks and then encrypted. Each chunk is packetized with about 5-10 235 seconds of video data. After receiving peer list from super nodes, a 236 peer negotiates with some or, if necessary, all of the peers in the 237 list to find out what chunks they have. Then the peer makes decision 238 about from which peers to get the chunks. No peer capability 239 information is exchanged in the Peer Protocol. 240 +---------------+ +-------------------+ 241 | Version Server| | Tracker Server | 242 +---------------+ +-------------------+ 243 \ | 244 \ | 245 \ | +---------------+ 246 \ | |Graphics Server| 247 \ | +---------------+ 248 \ | | 249 +--------------+ +-------------+ +--------------+ 250 |Content Server|--------| Peer1 |--------|Backend Server| 251 +--------------+ +-------------+ +--------------+ 252 | 253 | 254 | 255 | 256 +------------+ +---------+ 257 | Super Node |-------| Peer2 | 258 +------------+ +---------+ 260 Figure 1, Architecture of Joost system 262 3.1.2. Octoshape 264 CNN has been working with a P2P Plug-in, from a Denmark-based company 265 Octoshape, to broadcast its living streaming. Octoshape helps CNN 266 serve a peak of more than a million simultaneous viewers. It has 267 also provided several innovative delivery technologies such as loss 268 resilient transport, adaptive bit rate, adaptive path optimization 269 and adaptive proximity delivery. Figure 2 depicts the architecture 270 of the Octoshape system. 272 Octoshape maintains a mesh overlay topology. Its overlay topology 273 maintenance scheme is similar to that of P2P file-sharing 274 applications, such as BitTorrent. There is no Tracker server in 275 Octoshape, thus no Tracker Protocol is required. Peers obtain live 276 streaming from content servers and peers over Octoshape Protocol. 277 Several data streams are constructed from live stream. No data 278 streams are identical and any number K of data streams can 279 reconstruct the original live stream. The number K is based on the 280 original media playback rate and the playback rate of each data 281 stream. For example, a 400Kbit/s media is split into four 100Kbit/s 282 data streams, and then k = 4. Data streams are constructed in peers, 283 instead of Broadcast server, which release server from large burden. 284 The number of data streams constructed in a particular peer equals 285 the number of peers downloading data from the particular peer, which 286 is constrained by the upload capacity of the particular peer. To get 287 the best performance, the upload capacity of a peer should be larger 288 than the playback rate of the live stream. If not, an artificial 289 peer may be added to deliver extra bandwidth. 291 Each single peer has an address book of other peers who is watching 292 the same channel. A Standby list is set up based on the address 293 book. The peer periodically probes/asks the peers in the standby 294 list to be sure that they are ready to take over if one of the 295 current senders stops or gets congested. [Octoshape] 297 Peer Protocol: The live stream is firstly sent to a few peers in the 298 network and then be spread to the rest. When a peer joins a channel, 299 it notifies all the other peers about its presence over Peer 300 Protocol, which will drive the others to add it into their address 301 books. Although [Octoshape] declares that each peer records all the 302 peers joining the channel, we suspect that not all the peers are 303 recorded, considering the notification traffic will be large and 304 peers will be busy with recording when a popular program starts in a 305 channel and lots of peers switch to this channel. Maybe some 306 geographic or topological neighbors are notified and the peer gets 307 its address book from these neighbors. 309 Peer Protocol: The live stream is firstly sent to a few peers in the 310 network and then spread to the rest of the network. When a peer 311 joins a channel, it notifies all the other peers about its presence 312 using Peer Protocol, which will drive the others to add it into their 313 address books. Although [Octoshape] declares that each peer records 314 all the peers joining the channel, we suspect that not all the peers 315 are recorded, considering the notification traffic will be large and 316 peers will be busy with recording when a popular program starts in a 317 channel and lots of peers switch to this channel. Maybe some 318 geographic or topological neighbors are notified and the peer gets 319 its address book from these nearby neighbors. 321 The peer sends requests to some selected peers for the live stream 322 and the receivers answers OK or not according to their upload 323 capacity. The peer continues sending requests to peers until it 324 finds enough peers to provide the needed data streams to redisplay 325 the original live stream. The details of Octoshape are (not?) 326 disclosed yet, we hope someone else can provide much specific 327 information. 328 +------------+ +--------+ 329 | Peer 1 |---| Peer 2 | 330 +------------+ +--------+ 331 | \ / | 332 | \ / | 333 | \ | 334 | / \ | 335 | / \ | 336 | / \ | 337 +--------------+ +-------------+ 338 | Peer 4 |----| Peer3 | 339 +--------------+ +-------------+ 341 ***************************************** 342 | 343 | 344 +---------------+ 345 | Content Server| 346 +---------------+ 348 Figure 2, Architecture of Octoshape system 350 3.1.3. PPLive 352 PPLive is one of the most popular P2P streaming software in China. 353 It has two major communication protocols. One is Registration and 354 peer discovery protocol, i.e. Tracker Protocol, and the other is P2P 355 chunk distribution protocol, i.e. Peer Protocol. Figure 3 shows the 356 architecture of PPLive. 358 Tracker Protocol: First, a peer gets the channel list from the 359 Channel server, in a way similar to that of Joost. Then the peer 360 chooses a channel and asks the Tracker server for the peerlist of 361 this channel. 363 Peer Protocol: The peer contacts the peers in its peerlist to get 364 additional peerlists, which are aggregated with its existing list. 365 Through this list, peers can maintain a mesh for peer management and 366 data delivery. 368 For the video-on-demand (VoD) operation, because different peers 369 watch different parts of the channel, a peer buffers up to a few 370 minutes worth of chunks within a sliding window to share with each 371 others. Some of these chunks may be chunks that have been recently 372 played; the remaining chunks are chunks scheduled to be played in the 373 next few minutes. Peers upload chunks to each other. To this end, 374 peers send to each other "buffer-map" messages; a buffer-map message 375 indicates which chunks a peer currently has buffered and can share. 376 The buffer-map message includes the offset (the ID of the first 377 chunk), the length of the buffer map, and a string of zeroes and ones 378 indicating which chunks are available (starting with the chunk 379 designated by the offset). PPlive transfer Data over UDP. 381 Video Download Policy of PPLive 383 1 Top ten peers contribute to a major part of the download 384 traffic. Meanwhile, the top peer session is quite short compared 385 with the video session duration. This would suggest that PPLive 386 gets video from only a few peers at any given time, and switches 387 periodically from one peer to another; 389 2 PPLive can send multiple chunk requests for different chunks to 390 one peer at one time; 392 PPLive maintains a constant peer list with relatively small number of 393 peers. [P2PIPTV-measuring] 394 +------------+ +--------+ 395 | Peer 2 |----| Peer 3 | 396 +------------+ +--------+ 397 | | 398 | | 399 +--------------+ 400 | Peer 1 | 401 +--------------+ 402 | 403 | 404 | 405 +---------------+ 406 | Tracker Server| 407 +---------------+ 409 Figure 3, Architecture of PPlive system 411 3.1.4. Zattoo 413 Zattoo is P2P live streaming system which serves over 3 million 414 registered users over European countries [Zattoo].The system delivers 415 live streaming using a receiver-based, peer-division multiplexing 416 scheme. Zattoo reliabily streams media among peers using the mesh 417 structure. 419 Figure 4 depcits a typical procedure of single TV channel carried 420 over Zattoo network. First, Zattoo system broadcasts live TV, 421 captured from satellites, onto the Internet. Each TV channel is 422 delivered through a separate P2P network. 423 ------------------------------- 424 | ------------------ | -------- 425 | | Broadcast | |---------|Peer1 |----------- 426 | | Servers | | -------- | 427 | Administrative Servers | ------------- 428 | ------------------------ | | Super Node| 429 | | Authentication Server | | ------------- 430 | | Rendezvous Server | | | 431 | | Feedback Server | | -------- | 432 | | Other Servers | |---------|Peer2 |----------| 433 | ------------------------| | -------- 434 ------------------------------| 435 Figure 4, Basic architecture of Zattoo system 437 Tracker(Rendezvous Server) Protocol: In order to receive the signal 438 the requested channel, registered users are required to be 439 authenticated through Zattoo Authentication Server. Upon 440 authentication, users obtain a ticket with specific lifetime. Then, 441 users contact Rendezvous Server with the ticket and identify of 442 interested TV channel. In return, the Rendezvous Server sends back a 443 list joined peers carrying the channel. 445 Peer Protocol: Similar to aforementioned procedures in Joost, PPLive, 446 a new Zattoo peer requests to join an existing peer among the peer 447 list. Upon the availability of bandwidth, requested peer decides how 448 to multiplex a stream onto its set of neighboring peers. When 449 packets arrive at the peer, sub-streams are stored for reassembly 450 constructing the full stream. 452 Note Zattoo relies on Bandwdith Estimation Server to initially 453 estimate the amount of available uplink bandwith at a peer. Once a 454 peer starts to forward substream to other peers, it receives QoS 455 feedback from other receivers if the quality of sub-stream drops 456 below a threshold. 458 3.1.5. PPStream 460 The system architecture and working flows of PPStream is similar to 461 PPLive. PPStream transfers data using mostly TCP, only occasionally 462 UDP. 464 Video Download Policy of PPStream 465 1 Top ten peers do not contribute to a large part of the download 466 traffic. This would suggest that PPStream gets the video from 467 many peers simultaneously, and its peers have long session 468 duration; 470 2 PPStream does not send multiple chunk requests for different 471 chunks to one peer at one time; 473 PPStream maintains a constant peer list with relatively large number 474 of peers. [P2PIPTV-measuring] 476 3.1.6. SopCast 478 The system architecture and working flows of SopCast is similar to 479 PPLive. SOPCast transfer data mainly using UDP, occasionally TCP; 481 Top ten peers contribute to about half of the total download traffic. 482 SOPCast's download policy is similar to PPLive's policy in that it 483 switches periodically between provider peers. However, SOPCast seems 484 to always need more than one peer to get the video, while in PPLive a 485 single peer could be the only video provider; 487 SOPCast's peer list can be as large as PPStream's peer list. But 488 SOPCast's peer list varies over time. [P2PIPTV-measuring] 490 3.1.7. TVants 492 The system architecture and working flows of TVants is similar to 493 PPLive. TVAnts is more balanced between TCP and UDP in data 494 transmission; 496 The system architecture and working flows of TVants is similar to 497 PPLive. TVAnts is more balanced between TCP and UDP in data 498 transmission; 500 TVAnts' peer list is also large and varies over time. [P2PIPTV- 501 measuring] 503 We extract the common Main components and steps of PPLive, PPStream, 504 SopCast and TVants, which is shown in Figure 5. 506 +------------+ 507 | Tracker | 508 /+------------+ 509 / 510 / +------+ 511 1,2/ /|Peer 1| 512 / / +------+ 513 / /3,4,6 514 +---------+/ +------+ 515 |New Peer |---------------|Peer 2| 516 +---------+\ 4,6 +------+ 517 |5 | \ 518 |---| \ +------+ 519 3,4,6 \|Peer 3| 520 +------+ 522 Figure 5, Main components and steps of PPLive, PPStream, SopCast and Tvants 524 The main steps are: 526 (1) A new peer registers with tracker / distributed hash table 527 (DHT) to join the peer group which shares a same channel / media 528 content; 530 (2) Tracker / DHT returns an initial peer list to the new peer; 532 (3) The new peer harvests peer lists by gossiping (i.e. exchange 533 peer list) with the peers in the initial peer list to aggregate 534 more peers sharing the channel / media content; 536 (4) The new peer randomly (or with some guide) selects some peers 537 from its peer list to connect and exchange peer information (e.g. 538 buffer map, peer status, etc) with connected peers to know where 539 to get what data; 541 (5) The new peer decides what data should be requested in which 542 order / priority using some scheduling algorithm and the peer 543 information obtained in Step (4); 545 (6) The new peer requests the data from some connected peers. 547 3.2. Tree-based P2P streaming systems 549 3.2.1. PeerCast 551 PeerCast adopts a Tree structure. The architecture of PeerCast is 552 shown in Figure 6. 554 Peers in one channel construct the Broadcast Tree and the Broadcast 555 server is the root of the Tree. A Tracker can be implemented 556 independently or merged in the Broadcast server. Tracker in Tree 557 based P2P streaming application selects the parent nodes for those 558 new peers who join in the Tree. A Transfer node in the Tree receives 559 and transfers data simultaneously. 561 Peer Protocol: The peer joins a channel and gets the broadcast server 562 address. First of all, the peer sends a request to the server, and 563 the server answers OK or not according to its idle capability. If 564 the broadcast server has enough idle capability, it will include the 565 peer in its child-list. Otherwise, the broadcast server will choose 566 at most eight nodes of its children and answer the peer. The peer 567 records the nodes and contacts one of them, until it finds a node 568 that can server it. 570 In stead of requesting the channel by the peer, a Transfer node 571 pushes live stream to its children, which can be a transfer node or a 572 receiver. A node in the tree will notify its status to its parent 573 periodically, and the latter will update its child-list according to 574 the received notifications. 575 ------------------------------ 576 | +---------+ | 577 | | Tracker | | 578 | +---------+ | 579 | | | 580 | | | 581 | +---------------------+ | 582 | | Broadcast server | | 583 | +---------------------+ | 584 |------------------------------ 585 / \ 586 / \ 587 / \ 588 / \ 589 +---------+ +---------+ 590 |Transfer1| |Transfer2| 591 +---------+ +---------+ 592 / \ / \ 593 / \ / \ 594 / \ / \ 595 +---------+ +---------+ +---------+ +---------+ 596 |Receiver1| |Receiver2| |Receiver3| |Receiver4| 597 +---------+ +---------+ +---------+ +---------+ 599 Figure 6, Architecture of PeerCast system 601 3.2.2. Conviva 603 Conviva[TM][conviva] is a real-time media control platform for 604 Internet multimedia broadcasting. For its early prototype, End 605 System Multicast (ESM) [ESM04] is the underlying networking 606 technology on organizing and maintaining an overlay broadcasting 607 topology. Next we present the overview of ESM. ESM adopts a Tree 608 structure. The architecture of ESM is shown in Figure 7. 610 ESM has two versions of protocols: one for smaller scale conferencing 611 apps with multiple sources, and the other for larger scale 612 broadcasting apps with Single source. We focus on the latter version 613 in this survey. 615 ESM maintains a single tree for its overlay topology. Its basic 616 functional components include two parts: a bootstrap protocol, a 617 parent selection algorithm, and a light-weight probing protocol for 618 tree topology construction and maintenance; a separate control 619 structure decoupled from tree, where a gossip-like algorithm is used 620 for each member to know a small random subset of group members; 621 members also maintain pathes from source. 623 Upon joining, a node gets a subset of group membership from the 624 source (the root node); it then finds parent using a parent selection 625 algorithm. The node uses light-weight probing heuristics to a subset 626 of members it knows, and evaluates remote nodes and chooses a 627 candidate parent. It also uses the parent selection algorithm to 628 deal with performance degradation due to node and network churns. 630 ESM Supports for NATs. It allows NATs to be parents of public hosts, 631 and public hosts can be parents of all hosts including NATs as 632 children. 634 ------------------------------ 635 | +---------+ | 636 | | Tracker | | 637 | +---------+ | 638 | | | 639 | | | 640 | +---------------------+ | 641 | | Broadcast server | | 642 | +---------------------+ | 643 |------------------------------ 644 / \ 645 / \ 646 / \ 647 / \ 648 +---------+ +---------+ 649 | Peer1 | | Peer2 | 650 +---------+ +---------+ 651 / \ / \ 652 / \ / \ 653 / \ / \ 654 +---------+ +---------+ +---------+ +---------+ 655 | Peer3 | | Peer4 | | Peer5 | | Peer6 | 656 +---------+ +---------+ +---------+ +---------+ 658 Figure 7, Architecture of ESM system 660 4. A common P2P Streaming Process Model 662 As shown in Figure 8, a common P2P streaming process can be 663 summarized based on Section 3: 665 1) When a peer wants to receive streaming content: 667 1.1) Peer acquires a list of peers/parent nodes from the 668 tracker. 670 1.2) Peer exchanges its content availability with the peers on 671 the obtained peer list, or requests to be adopted by the parent 672 nodes. 674 1.3) Peer identifies the peers with desired content, or the 675 available parent node. 677 1.4) Peer requests for the content from the identified peers, 678 or receives the content from its parent node. 680 2) When a peer wants to share streaming content with others: 682 2.1) Peer sends information to the tracker about the swarms it 683 belongs to, plus streaming status and/or content availability. 685 +---------------------------------------------------------+ 686 | +--------------------------------+ | 687 | | Tracker | | 688 | +--------------------------------+ | 689 | ^ | ^ | 690 | | | | | 691 | query | | peer list/ |streaming Status/ | 692 | | | Parent nodes |Content availability/ | 693 | | | |node capability | 694 | | | | | 695 | | V | | 696 | +-------------+ +------------+ | 697 | | Peer1 |<------->| Peer 2 | | 698 | +-------------+ content/+------------+ | 699 | join requests | 700 +---------------------------------------------------------+ 701 Figure 8, A common P2P streaming process model 703 The functionality of Tracker and data transfer in Mesh-based 704 application and Tree-based is a little different. In the Mesh-based 705 applications, such as Joost and PPLive, Tracker maintains the lists 706 of peers storing chunks for a specific channel or streaming file. It 707 provides peer list for peers to download from, as well as upload to, 708 each other. In the Tree-based applications, such as PeerCast and 709 Canviva, Tracker directs new peers to find parent nodes and the data 710 flows from parent to child only. 712 5. Security Considerations 714 This document does not consider security issues. It follows the 715 security consideration in [draft-zhang-ppsp-problem-statement]. 717 6. Acknowledgments 719 We would like to acknowledge Jiang xingfeng for providing good ideas 720 for this document. 722 7. Informative References 724 [PPLive] "www.pplive.com". 726 [PPStream] 727 "www.ppstream.com". 729 [CNN] "www.cnn.com". 731 [OctoshapeWeb] 732 "www.octoshape.com". 734 [Joost-Experiment] 735 Lei, Jun, et al., "An Experimental Analysis of Joost Peer- 736 to-Peer VoD Service". 738 [Sigcomm_P2P_Streaming] 739 Huang, Yan, et al., "Challenges, Design and Analysis of a 740 Large-scale P2P-VoD System", 2008. 742 [Octoshape] 743 Alstrup, Stephen, et al., "Introducing Octoshape-a new 744 technology for large-scale streaming over the Internet". 746 [Zattoo] "http: //zattoo.com/". 748 [Conviva] "http://www.rinera.com/". 750 [ESM04] Zhang, Hui., "End System Multicast, 751 http://www.cs.cmu.edu/~hzhang/Talks/ESMPrinceton.pdf", 752 May . 754 [Survey] Liu, Yong, et al., "A survey on peer-to-peer video 755 streaming systems", 2008. 757 [draft-zhang-alto-traceroute-00] 758 "www.ietf.org/internet-draft/ 759 draft-zhang-alto-traceroute-00.txt". 761 [P2PStreamingSurvey] 762 Zong, Ning, et al., "Survey of P2P Streaming", Nov. 2008. 764 [P2PIPTV_measuring] 765 Silverston, Thomas, et al., "Measuring P2P IPTV Systems". 767 [Challenge] 768 Li, Bo, et al., "Peer-to-Peer Live Video Streaming on the 769 Internet: Issues, Existing Approaches, and Challenges", 770 June 2007. 772 Authors' Addresses 774 Gu Yingjie 775 Huawei 776 Baixia Road No. 91 777 Nanjing, Jiangsu Province 210001 778 P.R.China 780 Phone: +86-25-84565868 781 Fax: +86-25-84565888 782 Email: guyingjie@huawei.com 784 Zong Ning 785 Huawei 786 Baixia Road No. 91 787 Nanjing, Jiangsu Province 210001 788 P.R.China 790 Phone: +86-25-84565866 791 Fax: +86-25-84565888 792 Email: zongning@huawei.com 794 Hui Zhang 795 NEC Labs America. 797 Email: huizhang@nec-labs.com 799 Zhang Yunfei 800 China Mobile 802 Email: zhangyunfei@chinamobile.com 804 Lei Jun 805 University of Goettingen 807 Phone: +49 (551) 39172032 808 Email: lei@cs.uni-goettingen.de 810 Gonzalo Camarillo 811 Ericsson 813 Email: Gonzalo.Camarillo@ericsson.com 814 Liu Yong 815 Polytechnic University 817 Email: yongliu@poly.edu