idnits 2.17.1 draft-gu-ppsp-survey-00.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.) ** 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 19, 2009) is 5308 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: 'TM' is mentioned on line 361, but not defined == Missing Reference: 'P2PIPTV-measuring' is mentioned on line 507, but not defined == Unused Reference: 'PPLive' is defined on line 631, but no explicit reference was found in the text == Unused Reference: 'PPStream' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'CNN' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'OctoshapeWeb' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'Joost-Experiment' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'Conviva' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'Survey' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'P2PStreamingSurvey' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'Challenge' is defined on line 672, but no explicit reference was found in the text Summary: 3 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 22, 2010 Hui. Zhang 6 NEC Labs America. 7 Yunfei. Zhang 8 China Mobile 9 October 19, 2009 11 Survey of P2P Streaming Applications 12 draft-gu-ppsp-survey-00 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 22, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document presents a survey of popular Peer-to-Peer streaming 51 applications on the Internet. We focus on the Architecture and Peer 52 Protocol/Tracker Signaling Protocol description in the presentation, 53 and study a selection of well-known P2P streaming systems, including 54 Joost, PPlive, and more. Through the survey, we summarize a common 55 P2P streaming process model and the correspondent signaling process 56 for P2P Streaming Protocol standardization. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 3 62 3. Survey of P2P streaming system . . . . . . . . . . . . . . . . 4 63 3.1. Joost . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Octoshape . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. PeerCast . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.4. Conviva . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.5. PPLive . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.6. PPStream . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.7. SopCast . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 3.8. TVants . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4. A common P2P Streaming Process Model . . . . . . . . . . . . . 13 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 74 7. Informative References . . . . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 Toward standardizing the signaling protocols used in today's Peer-to- 80 Peer (P2P) streaming applications, we surveyed several popular P2P 81 streaming systems on their architectures and signaling protocols 82 between peers, as well as, between peers and trackers. The studied 83 P2P streaming systems, running worldwide or domestically, include 84 PPLive, Joost, Cybersky-TV, Octoshape, and more. This document does 85 not intend to cover all design options of P2P streaming applications. 86 Instead, we choose a representative set of applications and focus on 87 the respective signaling characteristics of each kind. Through the 88 survey, we generalize a common streaming process model from those P2P 89 streaming systems, and summarize the companion signaling process as 90 the base of P2P Streaming Protocol standardization. 92 2. Terminologies and concepts 94 Chunk: A chunk is a basic unit of partitioned streaming media, which 95 is used by a peer for the purpose of storage, advertisement and 96 exchange among peers [Sigcomm:P2P streaming]. 98 Content Distribution Network (CDN) node: A CDN node refers to a 99 network entity that usually is deployed at the network edge to store 100 content provided by the original servers, and serves content to the 101 clients located nearby topologically. 103 Live streaming: The scenario where all clients receive streaming 104 content for the same ongoing event. The lags between the play points 105 of the clients and that of the streaming source are small.. 107 P2P cache: A P2P cache refers to a network entity that caches P2P 108 traffic in the network, and either transparently or explicitly 109 distributes content to other peers. 111 P2P streaming protocols: P2P streaming protocols refer to multiple 112 protocols such as streaming control, resource discovery, streaming 113 data transport, etc. which are needed to build a P2P streaming 114 system. 116 Peer/PPSP peer: A peer/PPSP peer refers to a participant in a P2P 117 streaming system. The participant not only receives streaming 118 content, but also stores and uploads streaming content to other 119 participants. 121 PPSP protocols: PPSP protocols refer to the key signaling protocols 122 among various P2P streaming system components, including the tracker 123 and peers. PPSP protocols are a part of P2P streaming protocols. 125 Swarm: A swarm refers to a group of clients (i.e. peers) sharing the 126 same content (e.g. video/audio program, digital file, etc) at a given 127 time. 129 Tracker/PPSP tracker: A tracker/PPSP tracker refers to a directory 130 service which maintains the lists of peers/PPSP peers storing chunks 131 for a specific channel or streaming file, and answers queries from 132 peers/PPSP peers. 134 Video-on-demand (VoD): The scenario where different clients watch 135 different parts of the media recorded and stored during past events. 137 3. Survey of P2P streaming system 139 3.1. Joost 141 Joost announced to give up P2P technology last year. However, as a 142 once very popular P2P streaming application, it's worthwhile to 143 understand how Joost works. 145 The key components of Joost include servers, super nodes and peers. 146 There are 5 types of servers: Tracker server, Version server, Backend 147 server, Content server and Graphics server. The architecture of 148 Joost system is shown in Figure 1. 150 First, we introduce the functionalities of Joost's key components 151 through three basic phases. Then we will discuss the Peer protocol 152 and Tracker protocol of Joost. 154 Installation: Backend server is involved in the installation phase. 155 Backend server provides peer with an initial channel list in a SQLite 156 file. No other parameters, such as local cache, node ID, or 157 listening port, are configured in this file. 159 Bootstrapping: In case of a newcomer, Tracker server provides several 160 super node addresses and possibly some content server addresses. 161 Then the peer connects Version server for the latest software 162 version. Finally, the peer starts to connect some super nodes to 163 obtain the list of other available peers and begin streaming video 164 contents. Different from Skype, super nodes in Joost only deal with 165 control traffic. They do not relay/forward any media data. 167 Channel switching: Super nodes are responsible for redirecting 168 clients to content server or peers. 170 Peers communicate with servers over HTTP/HTTPs and with super nodes/ 171 other peers over UDP. 173 Tracker Protocol: Because there are super nodes responsible for 174 providing the peerlist/content servers, protocol spoken between 175 tracker server and peers is rather simple. Peers get the addresses 176 of super nodes and content servers from Tracker server over HTTP. 177 After that, Tracker sever will not appear in any stage, e.g. channel 178 switching, VoD interaction. In fact, the protocol spoken between 179 peers and super nodes is more like what we normally called "Tracker 180 Protocol". It enables super nodes to check peer status, maintain 181 peer lists for several, if not all, channels. It provides peer list/ 182 content servers to peers. So in the rest of this section, when we 183 mention Tracker Protocol, we mean the one spoken between peers and 184 super nodes. 186 Peers will communicate with super nodes in some scenarios using 187 Tracker Protocol. 189 1 When a peer starts Joost software, after the installation and 190 bootstrapping, the peer will communicate with one or several super 191 nodes to get a list of available peers/content servers. 193 2 For on-demand video functions, super nodes periodically exchange 194 small UDP packets for peer management. 196 3 When switching between channels, peers contact super nodes and the 197 latter help the peers find available peers to fetch the requested 198 media data. 200 Peer Protocol: Until now, we have not gotten enough materials to show 201 what is negotiation process between peers. However, we try to 202 reverse-engineer what is negotiated based on the data in [Joost- 203 experiment]. We omitted the analysis process and directly show our 204 conclusion. Media data in Joost is split into chunks and then 205 encrypted. A chunk is about 5-10 seconds of video data. After 206 receiving peer list from super nodes, a peer negotiates with some or 207 all of the peers in the list to find out what chunks they have. Then 208 the peer makes decision about from which peers to get the chunks. No 209 peer capability information is exchanged in the Peer Protocol. 211 +---------------+ +-------------------+ 212 | Version Server| | Tracker Server | 213 +---------------+ +-------------------+ 214 \ | 215 \ | 216 \ | +---------------+ 217 \ | |Graphics Server| 218 \ | +---------------+ 219 \ | | 220 +--------------+ +-------------+ +--------------+ 221 |Content Server|--------| Peer1 |--------|Backend Server| 222 +--------------+ +-------------+ +--------------+ 223 | 224 | 225 | 226 | 227 +------------+ +---------+ 228 | Super Node |-------| Peer2 | 229 +------------+ +---------+ 231 Figure 1, Architecture of Joost system 233 3.2. Octoshape 235 CNN has been working with a P2P Plug-in, from a Denmark-based company 236 Octoshape, to broadcast its living streaming. Octoshape helps CNN 237 serve a peak of more than a million simultaneous viewers. Figure 2 238 depicts the architecture of the Octoshape system. 240 Octoshape maintains a mesh overlay topology. Its overlay topology 241 maintenance scheme is similar to that of P2P file-sharing 242 applications, such as BitTorrent. There is no Tracker server in 243 Octoshape, thus no Tracker Protocol. Peers obtain live streaming 244 from content servers and peers over Octoshape Protocol. Several data 245 streams are constructed from live stream. No data streams are 246 identical and any number K of data streams can reconstruct the 247 original live stream. The number K is based on the original media 248 playback rate and the playback rate of each data stream. For 249 example, a 400Kbit/s media is split into four 100Kbit/s data streams, 250 and then k = 4. Data streams are constructed in peers, instead of 251 Broadcast server, which release server from large burden. The number 252 of data streams constructed in a particular peer equals the number of 253 peers downloading data from the particular peer, which is constrained 254 by the upload capacity of the particular peer. To get the best 255 performance, the upload capacity of a peer should be larger than the 256 playback rate of the live stream. If not, an artificial peer may be 257 added to deliver extra bandwidth. 259 Each single peer has an address book of other peers who is watching 260 the channel. A Standby list is set up based on the address book. 261 The peer periodically probes/asks the peers in the standby list to be 262 sure that they are ready to take over if one of the current senders 263 stops or gets congested. [Octoshape] 265 Peer Protocol: The live stream is firstly sent to a few peers in the 266 network and then be spread to the rest. When a peer joins a channel, 267 it notifies all the other peers about its presence over Peer 268 Protocol, which will drive the others to add it into their address 269 books. Although [Octoshape] declares that each peer records all the 270 peers joining the channel, we suspect that not all the peers are 271 recorded, considering the notification traffic will be large and 272 peers will be busy with recording when a popular program starts in a 273 channel and lots of peers switch to this channel. Maybe some 274 geographic or topological neighbors are notified and the peer gets 275 its address book from these neighbors. 277 The peer sends requests to some selected peers for the live stream 278 and the receivers answers OK or not according to their upload 279 capacity. The peer continues sending requests to peers until it 280 finds enough peers to provide the needed data streams to redisplay 281 the original live stream. The details of Octoshape are (not?) 282 disclosed yet, we hope someone else can provide much specific 283 information. 284 +------------+ +--------+ 285 | Peer 1 |---| Peer 2 | 286 +------------+ +--------+ 287 | \ / | 288 | \ / | 289 | \ | 290 | / \ | 291 | / \ | 292 | / \ | 293 +--------------+ +-------------+ 294 | Peer 4 |----| Peer3 | 295 +--------------+ +-------------+ 297 ***************************************** 298 | 299 | 300 +---------------+ 301 | Content Server| 302 +---------------+ 304 Figure 2, Architecture of Octoshape system 306 3.3. PeerCast 308 PeerCast adopts a Tree structure. The architecture of PeerCast is 309 shown in Figure 3. 311 Peers in one channel construct the Broadcast Tree and the Broadcast 312 server is the root of the Tree. A Tracker can be implemented 313 independently or merged in the Broadcast server. Tracker in Tree 314 based P2P streaming application selects the parent nodes for those 315 new peers who join in the Tree. A Transfer node in the Tree receives 316 and transfers data simultaneously. 318 Peer Protocol: The peer joins a channel and gets the broadcast server 319 address. First of all, the peer sends a request to the server, and 320 the server answers OK or not according to its idle capability. If 321 the broadcast server has enough idle capability, it will include the 322 peer in its child-list. Otherwise, the broadcast server will choose 323 at most eight nodes of its children and answer the peer. The peer 324 records the nodes and contacts one of them, until it finds a node 325 that can server it. 327 In stead of requesting the channel by the peer, a Transfer node 328 pushes live stream to its children, which can be a transfer node or a 329 receiver. A node in the tree will notify its status to its parent 330 periodically, and the latter will update its child-list according to 331 the received notifications. 333 ------------------------------ 334 | +---------+ | 335 | | Tracker | | 336 | +---------+ | 337 | | | 338 | | | 339 | +---------------------+ | 340 | | Broadcast server | | 341 | +---------------------+ | 342 |------------------------------ 343 / \ 344 / \ 345 / \ 346 / \ 347 +---------+ +---------+ 348 |Transfer1| |Transfer2| 349 +---------+ +---------+ 350 / \ / \ 351 / \ / \ 352 / \ / \ 353 +---------+ +---------+ +---------+ +---------+ 354 |Receiver1| |Receiver2| |Receiver3| |Receiver4| 355 +---------+ +---------+ +---------+ +---------+ 357 Figure 3, Architecture of PeerCast system 359 3.4. Conviva 361 Conviva[TM][conviva] is a real-time media control platform for 362 Internet multimedia broadcasting. For its early prototype, End 363 System Multicast (ESM) [ESM04] is the underlying networking 364 technology on organizing and maintaining an overlay broadcasting 365 topology. Next we present the overview of ESM. ESM adopts a Tree 366 structure. The architecture of ESM is shown in Figure 4. 368 ESM has two versions of protocols: one for smaller scale conferencing 369 apps with multiple sources, and the other for larger scale 370 broadcasting apps with Single source. We focus on the latter version 371 in this survey. 373 ESM maintains a single tree for its overlay topology. Its basic 374 functional components include two parts: a bootstrap protocol, a 375 parent selection algorithm, and a light-weight probing protocol for 376 tree topology construction and maintenance; a separate control 377 structure decoupled from tree, where a gossip-like algorithm is used 378 for each member to know a small random subset of group members; 379 members also maintain pathes from source. 381 Upon joining, a node gets a subset of group membership from the 382 source (the root node); it then finds parent using a parent selection 383 algorithm. The node uses light-weight probing heuristics to a subset 384 of members it knows, and evaluates remote nodes and chooses a 385 candidate parent. It also uses the parent selection algorithm to 386 deal with performance degradation due to node and network churns. 388 ESM Supports for NATs. It allows NATs to be parents of public hosts, 389 and public hosts can be parents of all hosts including NATs as 390 children. 391 ------------------------------ 392 | +---------+ | 393 | | Tracker | | 394 | +---------+ | 395 | | | 396 | | | 397 | +---------------------+ | 398 | | Broadcast server | | 399 | +---------------------+ | 400 |------------------------------ 401 / \ 402 / \ 403 / \ 404 / \ 405 +---------+ +---------+ 406 | Peer1 | | Peer2 | 407 +---------+ +---------+ 408 / \ / \ 409 / \ / \ 410 / \ / \ 411 +---------+ +---------+ +---------+ +---------+ 412 | Peer3 | | Peer4 | | Peer5 | | Peer6 | 413 +---------+ +---------+ +---------+ +---------+ 415 Figure 4, Architecture of ESM system 417 3.5. PPLive 419 PPLive is one of the most popular P2P streaming software in China. 420 It has two major communication protocols. One is Registration and 421 peer discovery protocol, i.e. Tracker Protocol, and the other is P2P 422 chunk distribution protocol, i.e. Peer Protocol. Figure 5 shows the 423 architecture of PPLive. 425 Tracker Protocol: First, a peer gets the channel list from the 426 Channel server, in a way similar to that of Joost. Then the peer 427 chooses a channel and asks the Tracker server for the peerlist of 428 this channel. 430 Peer Protocol: The peer contacts the peers in its peerlist to get 431 additional peerlists, which are aggregated with its existing list. 433 For the video-on-demand (VoD) operation, because different peers 434 watch different parts of the channel, a peer buffers up to a few 435 minutes worth of chunks within a sliding window to share with each 436 others. Some of these chunks may be chunks that have been recently 437 played; the remaining chunks are chunks scheduled to be played in the 438 next few minutes. Peers upload chunks to each other. To this end, 439 peers send to each other "buffer-map" messages; a buffer-map message 440 indicates which chunks a peer currently has buffered and can share. 441 The buffer-map message includes the offset (the ID of the first 442 chunk), the length of the buffer map, and a string of zeroes and ones 443 indicating which chunks are available (starting with the chunk 444 designated by the offset). PPlive transfer Data over UDP. 446 Video Download Policy of PPLive 448 1 Top ten peers contribute to a major part of the download 449 traffic. Meanwhile, the top peer session is quite short compared 450 with the video session duration. This would suggest that PPLive 451 gets video from only a few peers at any given time, and switches 452 periodically from one peer to another; 454 2 PPLive can send multiple chunk requests for different chunks to 455 one peer at one time; 457 PPLive maintains a constant peer list with relatively small number of 458 peers. [P2PIPTV-measuring] 459 +------------+ +--------+ 460 | Peer 2 |----| Peer 3 | 461 +------------+ +--------+ 462 | | 463 | | 464 +--------------+ 465 | Peer 1 | 466 +--------------+ 467 | 468 | 469 | 470 +---------------+ 471 | Tracker Server| 472 +---------------+ 474 Figure 5, Architecture of PPlive system 476 3.6. PPStream 478 The system architecture and working flows of PPStream is similar to 479 PPLive. PPStream transfers data using mostly TCP, only occasionally 480 UDP. 482 Video Download Policy of PPStream 484 1 Top ten peers do not contribute to a large part of the download 485 traffic. This would suggest that PPStream gets the video from 486 many peers simultaneously, and its peers have long session 487 duration; 489 2 PPStream does not send multiple chunk requests for different 490 chunks to one peer at one time; 492 PPStream maintains a constant peer list with relatively large number 493 of peers. [P2PIPTV-measuring] 495 3.7. SopCast 497 The system architecture and working flows of SopCast is similar to 498 PPLive. SOPCast transfer data mainly using UDP, occasionally TCP; 500 Top ten peers contribute to about half of the total download traffic. 501 SOPCast's download policy is similar to PPLive's policy in that it 502 switches periodically between provider peers. However, SOPCast seems 503 to always need more than one peer to get the video, while in PPLive a 504 single peer could be the only video provider; 506 SOPCast's peer list can be as large as PPStream's peer list. But 507 SOPCast's peer list varies over time. [P2PIPTV-measuring] 509 3.8. TVants 511 The system architecture and working flows of TVants is similar to 512 PPLive. TVAnts is more balanced between TCP and UDP in data 513 transmission; 515 The system architecture and working flows of TVants is similar to 516 PPLive. TVAnts is more balanced between TCP and UDP in data 517 transmission; 519 TVAnts' peer list is also large and varies over time. [P2PIPTV- 520 measuring] 522 We extract the common Main components and steps of PPLive, PPStream, 523 SopCast and TVants, which is shown in Figure 6. 525 +------------+ 526 | Tracker | 527 /+------------+ 528 / 529 / +------+ 530 1,2/ /|Peer 1| 531 / / +------+ 532 / /3,4,6 533 +---------+/ +------+ 534 |New Peer |---------------|Peer 2| 535 +---------+\ 4,6 +------+ 536 |5 | \ 537 |---| \ +------+ 538 3,4,6 \|Peer 3| 539 +------+ 541 Figure 6, Main components and steps of PPLive, PPStream, SopCast and Tvants 543 The main steps are: 545 (1) A new peer registers with tracker / distributed hash table 546 (DHT) to join the peer group which shares a same channel / media 547 content; 549 (2) Tracker / DHT returns an initial peer list to the new peer; 551 (3) The new peer harvests peer lists by gossiping (i.e. exchange 552 peer list) with the peers in the initial peer list to aggregate 553 more peers sharing the channel / media content; 555 (4) The new peer randomly (or with some guide) selects some peers 556 from its peer list to connect and exchange peer information (e.g. 557 buffer map, peer status, etc) with connected peers to know where 558 to get what data; 560 (5) The new peer decides what data should be requested in which 561 order / priority using some scheduling algorithm and the peer 562 information obtained in Step (4); 564 (6) The new peer requests the data from some connected peers. 566 4. A common P2P Streaming Process Model 568 As shown in Figure 7, a common P2P streaming process can be 569 summarized from Section 3: 571 1) When a peer wants to receive streaming content: 573 1.1) Peer acquires a list of peers/parent nodes from the 574 tracker. 576 1.2) Peer exchanges its content availability with the peers on 577 the obtained peer list, or requests to be adopted by the parent 578 nodes. 580 1.3) Peer identifies the peers with desired content, or the 581 available parent node. 583 1.4) Peer requests for the content from the identified peers, 584 or receives the content from its parent node. 586 2) When a peer wants to share streaming content with others: 588 2.1) Peer sends information to the tracker about the swarms it 589 belongs to, plus streaming status and/or content availability. 591 +---------------------------------------------------------+ 592 | +--------------------------------+ | 593 | | Tracker | | 594 | +--------------------------------+ | 595 | ^ | ^ | 596 | | | | | 597 | query | | peer list/ |streaming Status/ | 598 | | | Parent nodes |Content availability/ | 599 | | | |node capability | 600 | | | | | 601 | | V | | 602 | +-------------+ +------------+ | 603 | | Peer1 |<------->| Peer 2 | | 604 | +-------------+ content/+------------+ | 605 | join requests | 606 +---------------------------------------------------------+ 607 Figure 7, A common P2P streaming process model 609 The functionality of Tracker and data transfer in Mesh-based 610 application and Tree-based is a little different. In the Mesh-based 611 applications, such as Joost and PPLive, Tracker maintains the lists 612 of peers storing chunks for a specific channel or streaming file. It 613 provides peer list for peers to download from, as well as upload to, 614 each other. In the Tree-based applications, such as PeerCast and 615 Canviva, Tracker directs new peers to find parent nodes and the data 616 flows from parent to child only. 618 5. Security Considerations 620 This document does not consider security issues. It follows the 621 security consideration in [draft-zhang-ppsp-problem-statement]. 623 6. Acknowledgments 625 We would like to acknowledge the following who provided feedback or 626 suggestions for this document: Jiang xingfeng, Yong Liu, Gonzalo 627 Camarillo. 629 7. Informative References 631 [PPLive] "www.pplive.com". 633 [PPStream] 634 "www.ppstream.com". 636 [CNN] "www.cnn.com". 638 [OctoshapeWeb] 639 "www.octoshape.com". 641 [Joost-Experiment] 642 Lei, Jun, et al., "An Experimental Analysis of Joost Peer- 643 to-Peer VoD Service". 645 [Sigcomm_P2P_Streaming] 646 Huang, Yan, et al., "Challenges, Design and Analysis of a 647 Large-scale P2P-VoD System", 2008. 649 [Octoshape] 650 Alstrup, Stephen, et al., "Introducing Octoshape-a new 651 technology for large-scale streaming over the Internet". 653 [Conviva] "http://www.rinera.com/". 655 [ESM04] Zhang, Hui., "End System Multicast, 656 http://www.cs.cmu.edu/~hzhang/Talks/ESMPrinceton.pdf", 657 May . 659 [Survey] Liu, Yong, et al., "A survey on peer-to-peer video 660 streaming systems", 2008. 662 [draft-zhang-alto-traceroute-00] 663 "www.ietf.org/internet-draft/ 664 draft-zhang-alto-traceroute-00.txt". 666 [P2PStreamingSurvey] 667 Zong, Ning, et al., "Survey of P2P Streaming", Nov. 2008. 669 [P2PIPTV_measuring] 670 Silverston, Thomas, et al., "Measuring P2P IPTV Systems". 672 [Challenge] 673 Li, Bo, et al., "Peer-to-Peer Live Video Streaming on the 674 Internet: Issues, Existing Approaches, and Challenges", 675 June 2007. 677 Authors' Addresses 679 Gu Yingjie 680 Huawei 681 Baixia Road No. 91 682 Nanjing, Jiangsu Province 210001 683 P.R.China 685 Phone: +86-25-84565868 686 Fax: +86-25-84565888 687 Email: guyingjie@huawei.com 689 Zong Ning 690 Huawei 691 Baixia Road No. 91 692 Nanjing, Jiangsu Province 210001 693 P.R.China 695 Phone: +86-25-84565866 696 Fax: +86-25-84565888 697 Email: zongning@huawei.com 699 Hui Zhang 700 NEC Labs America. 702 Email: huizhang@nec-labs.com 703 Zhang Yunfei 704 China Mobile 706 Email: zhangyunfei@chinamobile.com