idnits 2.17.1 draft-chen-decade-intgr-livestr-exmp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- ** There are 34 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 (March 14, 2011) is 4763 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 824, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DECADE L. Chen 3 Internet-Draft H. Liu 4 Intended status: Informational Yale University 5 Expires: September 15, 2011 Z. Huang 6 X. Chen 7 HUAWEI Technologies 8 March 14, 2011 10 Integration Examples of DECADE System 11 draft-chen-decade-intgr-livestr-exmp-01 13 Abstract 15 DECADE is an in-network storage infrastructure which is under 16 discussions and constructions. It can be integrated into Peer-to- 17 Peer (P2P) applications to achieve more efficient content 18 distributions. This document represents two detailed examples of how 19 to integrate DECADE into P2P applications (live streaming and file 20 sharing). Specifically, it describes mainly about: 1) a preliminary 21 DECADE client API; 2) a P2P live streaming integration with DECADE; 22 3) a P2P file sharing integration with DECADE; 4) tests on our DECADE 23 integrarions and 5) an application performance analysis from the 24 tests. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 15, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 4 70 2.3. DECADE Module . . . . . . . . . . . . . . . . . . . . . . 5 71 2.4. P2P LiveStreaming Client (P2PLS Client) . . . . . . . . . 5 72 2.5. DECADE Client . . . . . . . . . . . . . . . . . . . . . . 5 73 2.6. Vuze . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.7. DECADE Plugin . . . . . . . . . . . . . . . . . . . . . . 5 75 2.8. DECADE-Enabled Vuze . . . . . . . . . . . . . . . . . . . 5 76 2.9. Remote Controller . . . . . . . . . . . . . . . . . . . . 5 77 3. DECADE Client API . . . . . . . . . . . . . . . . . . . . . . 6 78 4. DECADE Integration of P2P LiveStreaming Client . . . . . . . . 6 79 4.1. DECADE Integration Architecture . . . . . . . . . . . . . 7 80 4.1.1. Data Access . . . . . . . . . . . . . . . . . . . . . 7 81 4.1.2. Message Control . . . . . . . . . . . . . . . . . . . 7 82 4.2. Challenges in DECADE Integration . . . . . . . . . . . . . 8 83 4.2.1. Limited Connection Slot . . . . . . . . . . . . . . . 8 84 4.2.2. Additional Control Latency . . . . . . . . . . . . . . 8 85 5. DECADE Integration of P2P Filesharing Client . . . . . . . . . 9 86 5.1. Vuze Client Design . . . . . . . . . . . . . . . . . . . . 9 87 5.2. DECADE-Enabled Vuze architecture Design . . . . . . . . . 9 88 5.3. DECADE-Enabled Vuze Communication Procedure . . . . . . . 11 89 6. Test Environment and Settings . . . . . . . . . . . . . . . . 12 90 6.1. Test Settings . . . . . . . . . . . . . . . . . . . . . . 13 91 6.2. Platforms and Components of P2PLS . . . . . . . . . . . . 13 92 6.2.1. EC2 DECADE Server . . . . . . . . . . . . . . . . . . 14 93 6.2.2. PlanetLab P2P LiveStreaming Client . . . . . . . . . . 14 94 6.2.3. Tracker . . . . . . . . . . . . . . . . . . . . . . . 14 95 6.2.4. Source Server . . . . . . . . . . . . . . . . . . . . 14 96 6.2.5. Test Controller . . . . . . . . . . . . . . . . . . . 15 97 6.3. Platforms and Components of Vuze . . . . . . . . . . . . . 15 98 6.3.1. EC2 DECADE Server . . . . . . . . . . . . . . . . . . 16 99 6.3.2. Vuze Client with DECADE Plugin . . . . . . . . . . . . 16 100 6.3.3. Remote Controller . . . . . . . . . . . . . . . . . . 16 101 6.3.4. Tracker . . . . . . . . . . . . . . . . . . . . . . . 16 102 6.3.5. HTTP Server . . . . . . . . . . . . . . . . . . . . . 16 103 6.3.6. PL Manager . . . . . . . . . . . . . . . . . . . . . . 16 104 7. Performance Analysis . . . . . . . . . . . . . . . . . . . . . 17 105 7.1. Performance Metrics . . . . . . . . . . . . . . . . . . . 17 106 7.1.1. P2P Live Streaming . . . . . . . . . . . . . . . . . . 17 107 7.1.2. Vuze . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 7.2. Result and Analysis . . . . . . . . . . . . . . . . . . . 17 109 7.2.1. P2P Live Streaming . . . . . . . . . . . . . . . . . . 17 110 7.2.2. Vuze . . . . . . . . . . . . . . . . . . . . . . . . . 18 111 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 112 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 113 10. Normative References . . . . . . . . . . . . . . . . . . . . . 20 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 116 1. Introduction 118 DECADE is an in-network storage infrastructure under discussions and 119 constructions. It can be integrated into Peer-to-Peer (P2P) 120 applications to achieve more efficient content distributions. 122 This draft introduces two instances of application integration with 123 DECADE. In our example system, the core component includes DECADE 124 server and DECADE-aware P2P clients (live streaming client and file- 125 sharing client). A DECADE server runs at Linux platform and is 126 designed to support interactive control and data transport for DECADE 127 clients. For live streaming case, we deployed a P2P live streaming 128 system called P2PLS (P2P Live Streaming). We also utilized a 129 preliminary API (Application Programming Interface) set, which is 130 supposed to be provided by DECADE, to enable P2PLS clients to 131 leverage DECADE in their data transmission. For file-sharing case, 132 we choose an open source P2P client software named Vuze which 133 supports user defining plugin to extend software functions. In this 134 draft, we introduce the structures of the both DECADE integration 135 applications, the DECADE related control flow, the environment of 136 tests on both integrations, and the system performance in the tests. 138 Please note that P2PLS and Vuze in this draft only represent the 139 usage case of "live streaming" and "file-sharing" out of a large 140 number of P2P applications, while DECADE itself can support other 141 applications. The API set of DECADE is an experimental design and 142 implementation. It is not a standard and is still under development. 143 Currently, DECADE in this draft is only a preliminary framwork of in- 144 network for P2P. It is designed to demonstrate the pros and cons of 145 in-network storage utilized by P2P applications rather than to reach 146 a final solution. 148 2. Concepts 150 2.1. P2P 152 Peer-to-Peer computing or networking is a distributed application 153 architecture that partitions tasks or work loads between peers. 154 Peers are equally privileged, equipotent participants in the 155 application. 157 2.2. DECADE Server 159 A DECADE server is implemented with DECADE protocols, management 160 mechanism and storage strategies. It is an important element to 161 provide DECADE services. In a DECADE server, we have a number of 162 Data Lockers each of which is a virtual account and private storage 163 space for applications. 165 2.3. DECADE Module 167 DECADE module is a functional component for application clients to 168 utilize DECADE. This component serves as an application-specific 169 interface between a particular application and DECADE servers. It 170 can be a simple implementation of basic DECADE access APIs, or a 171 smart realization which integrates application-specific control 172 strategies with DECADE APIs. 174 2.4. P2P LiveStreaming Client (P2PLS Client) 176 P2P LiveStreaming Client (P2PLS Client) is our self-maintained 177 version of a native P2P live streaming application. It is one 178 example out of a large number of P2P applications. 180 2.5. DECADE Client 182 DECADE client is an integration of a native P2P client and a DECADE 183 module. It is not required to embed DECADE module into native P2P 184 clients, since it can also be an independent conponent running at a 185 remote server. 187 2.6. Vuze 189 Vuze is an open source P2P application, which uses BitTorrent 190 protocol for message and data exchanging. Vuze provides a set of 191 interfaces which support users to develop particular extensions. 193 2.7. DECADE Plugin 195 A plugin built into Vuze to implement DECADE functions including 196 getting/putting data from/to DECADE server and redirection 198 2.8. DECADE-Enabled Vuze 200 A Vuze client that is enabled by DECADE plugin. 202 2.9. Remote Controller 204 A controller which can control every Vuze client to start or stop 205 downloading tasks. It also has a function of collecting statistic 206 information of each Vuze client. It is a major operating platform. 208 3. DECADE Client API 210 In order to simplify the DECADE integration with P2P clients, we 211 provide an API set which covers the communications with DECADE 212 servers and token-generation. On top of this API, a P2P client can 213 develop its own application-specific control and data distribution 214 policies. 216 There are five basic interfaces: 218 o Get_Object: to get an object from a DECADE server with an 219 authorized token. The get operation can be classified into two 220 categories: Local Get and Remote Get. Local Get is to get an 221 object from a local DECADE server. Remote Get is to use a 222 client's local DECADE server to indirectly get an object from a 223 remote DECADE server. The object will be firstly passed to the 224 local DECADE server, then returned to the application client 226 o Put_Object: to store an object into a DECADE server with an 227 authorized token. A client can either store an object into its 228 local DECADE server or into other clients' DECADE servers, if it 229 has an authorized token. Both of the operations are direct, for 230 we don't provide indirectly storing (i.e. remote put). 232 o Delete_Object: to delete an object in a DECADE server explicitly 233 with an authorized token. Note that an object can also be deleted 234 implicitly by setting an expired time or a specific TTL. 236 o Status_Query: to query current status of an application itself, 237 including listing stored objects, resource usage, etc.. Such 238 information is private. 240 o Generate_Token: to generate an authorized token. The token can be 241 used to access an application client's local DECADE server, or 242 passed to other clients to allow them to access the client's local 243 DECADE server. 245 4. DECADE Integration of P2P LiveStreaming Client 247 We integrate a DECADE module into a P2P live streaming application-- 248 P2PLS, in order that clients of this application can easily leverage 249 DECADE in their data distributions. 251 4.1. DECADE Integration Architecture 253 The architecture of the P2PLS application and DECADE integration is 254 shown in Figure 1: 256 +---------------+ +---------------+ 257 | DECADE | | DECADE | 258 | Peer | | Peer | 259 |+-------------+| +---------------+ |+-------------+| 260 ||DECADE Module||---| DECADE Server |---||DECADE Module|| 261 |+------^------+| +---------------+ |+------^------+| 262 | API | | | API | | 263 |+------v------+| +---------------+ |+------v------+| 264 ||Native Client||---| Tracker |---||Native Client|| 265 |+-------------+| +---------------+ |+-------------+| 266 +---------------+ +---------------+ 268 Figure 1 270 A DECADE-integrated P2PLS client uses DECADE module to communicate 271 with its DECADE server and transmit data between itself and its 272 DECADE server. It is compatible with its original P2P protocol, 273 while it also uses a DECADE protocol to exchange DECADE related 274 messages with other peers. 276 4.1.1. Data Access 278 DECADE module is called whenever a client wants to get data objects 279 from (or put data objects into) its DECADE server. Each data object 280 transferred between a client and its DECADE server should go through 281 DECADE module. Neither the DECADE server and the original client 282 knows each other. A data object is a data transfer unit between 283 DECADE servers and application clients. Its size can be application- 284 customized, according to variable requirements of performance or 285 sensitive factors (e.g. low latency, high bandwidth utilization). 287 4.1.2. Message Control 289 Control and data plane decoupling is a design principle of DECADE. 290 Control messages are propagated in an original P2P way. DECADE only 291 introduces an additional control message between DECADE module which 292 carries DECADE authorized token. By exchanging DECADE authorized 293 tokens, P2P live streaming clients can retrieve or store data objects 294 into or from others' DECADE servers. 296 4.2. Challenges in DECADE Integration 298 One essential objective of DECADE integration is to improve (or at 299 least not to hurt) the application performance. However, as a brand 300 new architecture, DECADE has some inherit challenges which will 301 potentially be harmful to application performance. In our P2P live 302 streaming case, we met mainly two such limitations of DECADE: 304 4.2.1. Limited Connection Slot 306 Limited Connection Slot: In native P2P systems, a peer can establish 307 tens or hunderds of concurrent connections with other peers. 308 However, this situation can hardly be ture when it is integrated with 309 DECADE because it is too expensive for DECADE servers to maintain so 310 many connections for each peer. Typically, each DECADE peer only 311 have m connection slots, which means it can only at most have m 312 active connections with its DECADE server simultaneously. A 313 potential "side effect" of limited connection slot is that the 314 content availability and downloading rate might be impacted 315 negatively by fewwer connections carrying data traffic. This 316 requests us to adjust the peer's behavior in resource allocation, 317 downloading/uploading scheduling, etc. to fully utilize the 318 connection slots to archieve a satisfying and robust data 319 downloading. 321 o Batch Request: In order to fully utilize the connection bandwidth 322 of a DECADE server and reduce overhead, a P2PLS client may combine 323 multiple requests in a single request to DECADE server. Note that 324 for the sake of improving data transfer efficiency in P2P live 325 streaming, we may combine multiple data requests into a batch 326 request. Generally, a batch may consist of different kinds of 327 access requests. 329 o Data Object Size: In typical P2P live streaming application, the 330 size of a data block is relatively small, considering to reduce 331 end-to-end transport latency. However, existing data size may 332 incur large control overhead and low transport utilization. A 333 larger data object size may be needed to utilize DECADE more 334 efficiently. 336 4.2.2. Additional Control Latency 338 Addtional Control Latency: In native P2P systems, when an uploader 339 decides to reply a request for a piece, it sends the piece out 340 directly. Nevertheless, in DECADE-aware P2P systems, the uploader 341 typically only replies with a token of the piece. And then the 342 downloader will leverage this token to fetch the piece from the 343 uploader's DECADE server. This process obviously introduces 344 additional control latency compared with native P2P systems. It is 345 even more serious in latency sensitive applications such as P2P live 346 streaming. We need to consider how to reduce such additional delay 347 or how to compensate the lose with other inherit advantages of 348 DECADE. 350 o Range Token: One way to reduce request latency is to use range 351 token. A P2PLS client may piggyback a range token when it 352 propagates its bitmap to its neighbors, to indicate that all 353 available pieces in the bitmap are accassable by this range token. 354 Then instead of requesting specific pieces from this client and 355 waiting for response, the neighbors can directly use this range 356 token to access data in DECADE servers. Note that this method not 357 only reduce request latency, but also reduce message overhead. 359 With these adjustments and strategies, DECADE clients' performance 360 was not impacted by the liminations of DECADE and was even better 361 than native clients' as we will see in following sections. 363 5. DECADE Integration of P2P Filesharing Client 365 We integrate DECADE with a popular P2P file-sharing application-- 366 Vuze. 368 5.1. Vuze Client Design 370 Note that Vuze client is classified into two different kinds - Native 371 Vuze and DECADE-Enabled Vuze. When running Native Vuze, it behaves 372 as ordinary BitTorrent client: some Vuze clients upload data for 373 others to download. When using DECADE-Enabled Vuze, the 374 communication and data exchange processes are changed. The uploader 375 uploads data to its DECADE server, and downloaders download data from 376 DECADE servers. By this means, uplink traffic can be reduced sharply 377 and download performance can be improved. It is beneficial for ISPs 378 to save the last-mile uplink bandwidth. 380 5.2. DECADE-Enabled Vuze architecture Design 382 DECADE plugin is a key component of our demo system. It has several 383 interfaces with other components as following: 385 Interface between DECADE plugin and DECADE server: DECADE plugin can 386 upload and download data from DECADE server. It also includes other 387 functions such as user registration, application registration etc. 389 Interface between DECADE plugin and Vuze client: DECADE plugin can 390 register a listener to intercept the BitTorrent message such as 391 "BT_Request" message from or to Vuze client, encapsulate the data 392 from DECADE server into "BT_Piece" message and put the "BT_Piece" 393 message into incoming message queue, read the block/piece data from 394 the disk when seeding (to upload the data to DECADE server), and 395 start or stop the download tasks, all these functions are supported 396 in the Plugin API provided by Vuze. 398 Interface between DECADE plugins: When DECADE plugin intercepts the 399 "BT_Request" message from other Vuze clients, local DECADE plugin 400 sends "Redirect" message to remote DECADE plugin to authorize it to 401 download the piece data from the DECADE server. 403 Interface between DECADE plugin and Remote Controller: DECADE plugin 404 registers with Remote Controller after starting up, Remote Controller 405 can control all the Vuze clients to start, stop or resume the 406 download tasks through DECADE plugins. 408 The system architecture is as follow: 410 _____________ _____________ 411 | DACADE | | DECADE | 412 | Server |---------------| Server | 413 |____________| |____________| 414 ^ ^ 415 | | 416 ______|______ ______|______ 417 | | | | | | 418 | P2P | Peer | | P2P | Peer | 419 | | | | | | _____________ 420 | ____v____ | | ____v____ | | Remote | 421 | |DECADE | | | | DECADE | | | Controller | 422 | |Plugin | |-------------- | | Plugin | |----------------|____________| 423 | |________| | | |________| | | 424 | ^ ^ | | ^ | | 425 | | |__|_______________|_____|______|______________________| 426 | PluginAPI | | PluginAPI | 427 | | | | | | 428 | ____v____ | | ____v____ | 429 | | | | | | | | 430 | | Vuze | |-------------- | | Vuze | | 431 | |________| | | |________| | 432 |____________| |____________| 434 Figure 2 436 5.3. DECADE-Enabled Vuze Communication Procedure 438 A DECADE plugin can change the data path of BitTorrent download by 439 using a "Redirect" message. 441 The detailed communication procedure is as following: 443 o When each client starts the download task ,it will try to connect 444 the tracker to get peer list and then send "BT_Request" message to 445 other peers in peer list. 447 o If the DECADE plugin is enabled, then it will intercept the 448 incoming "BT_Request" message from other Vuze clients, and then 449 reply with a "Redirect" message which includes DECADE server's 450 address, authorization token and so on to the requester. 452 o When a DECADE plugin receives a "Redirect" message, it will 453 connect to the DECADE server according to message context and send 454 "Remote Get" message to the DECADE server to request the data, 455 then wait for response. 457 o When a DECADE server receives a "Remote Get" message, it will 458 check the server IP address in the message, Case 1: if the address 459 equals to its own IP address, then it will send the data to the 460 requester from its local disk/memory; Case 2: if the address is 461 not equal to its own IP address, then it will send the "Remote 462 Get" message to that address, to fetch the data, and then send the 463 data to the requester. The data will be cached in the server 464 locally for use by other requesters. 466 o When a DECADE plugin obtains the data, it will encapsulate the 467 data into a standard "BT_Piece" message and send to Vuze client, 468 then the client can write the data block into storage. 470 The detailed communication diagram is as follow: 472 _________ __________ __________ ________ __________ __________ 473 | | | DACADE | | DACADE | | | | DECADE | | DECADE | 474 | Vuze1 | | Plugin1 | | Plugin2 | | Vuze2 | | Server1 | | Server2 | 475 |________| |_________| |_________| |_______| |_________| |_________| 476 | | | | | | 477 | | HandShake | | | | 478 |k----------|-----------------|---------->| | | 479 | |Azureus HandShake| | | | 480 |k----------|-----------------|---------->| | | 481 | | BT_BitField | | | | 482 |k----------|-----------------|---------->| | | 483 | | BT_Request | | | | 484 |-----------|---------------->| | | | 485 | | | | | | 486 | | Redirect | | | | 487 | |k----------------| | | | 488 | | DACADE RemoteGet | | 489 | |---------------------------------------->| | 490 | | | | | DACADE Get | 491 | | | | |----------->| 492 | | | | | DACADE Data| 493 | | | | |k-----------| 494 | | DACADE Data | | 495 | |k----------------------------------------| | 496 | | | | | | 497 | BT_Piece | | | | | 498 |k----------| | | | | 499 | | | | | | 501 Figure 3 503 6. Test Environment and Settings 505 In order to demonstrate the performance of our DECADE implementation 506 and DECADE-integrated P2P live streaming and file-sharing 507 applications, we conduct some experimental tests in Amazon EC2 and 508 PlanetLab. We perform a pair of comparative experiments: DECADE 509 integrated P2P application v.s. native P2P application, in the same 510 environment using the same settings. 512 6.1. Test Settings 514 Our tests ran on a wide-spread area and diverse platforms, including 515 a famous commercial cloud platform, Amazon EC2 and a well-known 516 testbed, PlanetLab. The environment settings are as following: 518 o EC2 Regions: we setup DECADE servers in Amazon EC2 cloud, 519 including all four regions around the world, US east, US west, 520 Europe and Asia. 522 o PlanetLab: we run our P2P live streaming clients and P2P file- 523 sharing clients (both DECADE integrated and native clients) on 524 PlanetLab of a wild-spread area. 526 o Arrival pattern: we made all the clients join into the system 527 within a short duration to simulate a flash crowd scenario. 529 o Total Bandwidth: for a fair comparison, we set the system's total 530 supply bandwidth to be exact the same in both test. 532 6.2. Platforms and Components of P2PLS 534 In the tests, we have different functional components running in 535 different platforms, including DECADE servers, P2P live streaming 536 clients(DECADE integrated or Native), Tracker, Source server and Test 537 Controller, as shown in Figure 4. 539 +----------+ +------------+ +------------+ 540 | P2PLS | /| DECADE |----| DECADE | 541 | Manager | / | Server | | Server | 542 +--------^\+ / +-----|------+ +------|-----+ EC2 543 ___________\/_________|__________________|_______ 544 /\ | | 545 +---------/+ \ +-----|------+ +------|-----+ 546 | P2PLS ^ \ | P2PLS ^ ^ P2PLS | 547 | Source |\ \| Client |\ /| Client | 548 +-----|----+ \ \------^-----+ \/ +------^-----+ Planetlab 549 ______|_______\__\_____|_______/\________|_______ 550 | \ \ | / \ | 551 +-----|----+ v--v---v-----v v------v-----+ 552 | Streaming| | P2PLS | | Test | 553 | Files | | Tracker | | Controller | 554 +----------+ +------------+ +------------+ Yale Lab 556 P2PLS represents to P2P LiveStreaming. 558 Figure 4 560 6.2.1. EC2 DECADE Server 562 DECADE Servers ran on Amazon EC2 small instances, with bandwidth 563 constraint. 565 6.2.2. PlanetLab P2P LiveStreaming Client 567 Both DECADE integrated and Native P2P live streaming clients ran on 568 planetlab which spreads in various locations around the world. The 569 DECADE integrated P2P live streaming clients connect to the closest 570 DECADE server according to its Geo-location distance to the servers. 571 DECADE integrated P2P live streaming clients use their DECADE servers 572 to upload to neighbors, instead of their own "last-mile" bandwidth. 574 6.2.3. Tracker 576 A native P2P live streaming tracker ran at Yale's laboratory and 577 served both DECADE integrated clients and native clients during the 578 test. 580 6.2.4. Source Server 582 A native P2P live streaming source server ran at Yale's laboratory 583 and serve both DECADE integrated clients and native clients during 584 the test. The capacity of source is equivalently constrain for both 585 cases. 587 6.2.5. Test Controller 589 Test Controller is a manager to control all machines' behaviors in 590 both EC2 and PlanetLab during the test. 592 6.3. Platforms and Components of Vuze 594 Test platforms includes Vuze client, tracker, DECADE Plugin, DECADE 595 Servers and other supportive components such as HTTP Server, FTP 596 Server and Remote Controller. 598 +-------------+ +-------------+ 599 | | | | 600 |DECADE Server| ... |DECADE Server| 601 | | | | 602 +-------------+ +-------------+ 603 / \ \ 604 / \ \ 605 / \ \ 606 / \ \ 607 / \ \ 608 / \ \ 609 / \ \ 610 +-------------+ +-------------+ +-------------+ +-------------+ 611 | Vuze client | | Vuze client | | Vuze client | | | 612 | with DECADE | | with DECADE | ... | with DECADE |--| Tracker | 613 | plugin | | plugin | | plugin | | | 614 +-------------+ +-------------+ +-------------+ +-------------+ 615 \ | / 616 \ | / 617 \ | / 618 \ | / 619 \ | / 620 \ | / 621 \ | / 622 \ | / 623 \ | / 624 +-------------+ +-------------+ +-------------+ +-------------+ 625 | | | Remote | | | | | 626 | PL Manager | | Controller | | HTTP Server | | FTP Server | 627 | | | | | | | | 628 +-------------+ +-------------+ +-------------+ +-------------+ 630 Figure 5 632 6.3.1. EC2 DECADE Server 634 DECADE Servers ran on Amazon EC2 small instances, with bandwidth 635 constraint. 637 6.3.2. Vuze Client with DECADE Plugin 639 Vuze clients are divided into one seeding client and multiple 640 leechers. Leechers run at PlanetLab, while the seeding client runs 641 at the Window 2003 server. DECADE Plugin will be automatically 642 loaded and run after Vuze client starts up. 644 6.3.3. Remote Controller 646 Remote controller can list all the Vuze clients in user interface and 647 control them to download a specific BitTorrent file. It runs at the 648 same Window 2003 server with the seeding client. 650 6.3.4. Tracker 652 Vuze client provides tracker capability, so we did not deploy our own 653 tracker. Vuze embedded tracker is enabled when making a torrent 654 file, the seeding client is also a tracker in this test. 656 6.3.5. HTTP Server 658 Torrent file will be put in the HTTP Server and the leechers will 659 retrieve the torrent file from HTTP Server after receiving the 660 download command from Remote Controller. We use Apache Tomcat which 661 is an open source software as HTTP Server. 663 6.3.6. PL Manager 665 PL Manager (PlanetLab experiment Manager)is a tool developed by 666 University of Washington, which presents a simple GUI to control 667 PlanetLab nodes and perform common tasks such as: 669 o Selecting nodes for your slice. 671 o Choosing nodes for your experiment based on CoMon information 672 about the nodes. 674 o Reliably deploying you experiment files. 676 o Executing commands / sets of commands on every node in parallel. 678 o Monitoring the progress of the experiment as a whole, as well as 679 viewing console output from the nodes. 681 7. Performance Analysis 683 During the test, Both DECADE integrated P2P live streaming clients 684 and DECADE integrated P2P file-sharing clients achieved impressively 685 better performance than native clients. 687 7.1. Performance Metrics 689 7.1.1. P2P Live Streaming 691 To measure the performance of a P2P live streaming client, we employ 692 mainly four metrics: 694 o Startup Delay: the duration from a peer joins the channel to the 695 moment it starts to play. 697 o Piece Missed Rate: the number of pieces a peer loses when playing 698 over the total number of pieces. 700 o Freeze Times: the number of times a peer re-buffers during 701 playing. 703 o Average Peer Uploading Rate: Average uploading bandwidth of a 704 peer. 706 7.1.2. Vuze 708 For the performance comparison of Native Vuze and DECADE-Enabled 709 Vuze, the same system bandwidth is provided through some parameter 710 settings. In Native Vuze, the system bandwidth is defined as the 711 amount of the uplink bandwidth from all the Vuze clients. The 712 maximum upload bandwidth (Bu) is configured to every Vuze client 713 before the test. Suppose the number of the Vuze clients is N, the 714 system bandwidth is Bu * N. In the DECADE-Enabled Vuze case, the same 715 bandwidth (Bu * N) is configured to the corresponding Ethernet port 716 of DECADE Server. 718 7.2. Result and Analysis 720 7.2.1. P2P Live Streaming 722 o Startup Delay: In the test, DECADE integrated P2P live streaming 723 clients startup around 35~40 seconds. some of them startup at 724 about 10 seconds. Native P2P live streaming clients startup 725 around 110~120 seconds. less than 20% of them startup within 100 726 seconds. 728 o Piece Missed Rate: In the test, both DECADE integrated P2P live 729 streaming clients and native P2P live streaming clients achieved a 730 good performance in pieces missed rate. Only about 0.02% of total 731 pieces missed in both cases. 733 o Freeze Times: In the test, native P2P live streaming clients 734 suffered from more freezing than DECADE Integrated P2P live 735 streaming clients by 40%. 737 o Average Peer Uploading Rate: In the test, according to our 738 settings, DECADE integrated P2P live streaming clients had no 739 upload in their "last-mile" access network. While in the native 740 P2P live streaming system, more than 70% of peers uploaded in a 741 rate that is much more than streaming rate. In another word, 742 DECADE can shift uploading traffic from clients' "last-mile" to 743 in-network devices, which saves a lot of expensive bandwidth on 744 access links.. 746 7.2.2. Vuze 748 Performance advantage is shown according to the test result of 749 experiment: 751 o 753 There is no upload data traffic from Vuze clients in the DECADE- 754 Enabled Vuze experiment, but in the Native Vuze experiment, the 755 upload data traffic from Vuze clients is the same as download data 756 traffic. Bandwidth resource is reduced in the last mile in the 757 DECADE-Enabled Vuze experiment. The test result is illustrated in 758 the following table. The download traffic and upload traffic 759 include data traffic and signal traffic. For the upload traffic 760 in the DECADE-enable Vuze, the data traffic is zero so the all 761 traffic is signal overhead. Though we used the same torrent file 762 in those two cases, the number of Vuze client was not the same 763 because the nodes in the Planet-lab are not always stable. 764 Therefore, the download traffic is a little different in two 765 cases. 767 +--------------------+--------------------+--------------------+ 768 | | | | 769 | | Download traffic | Upload traffic | 770 | | | | 771 +--------------------+--------------------+--------------------+ 772 | | | | 773 | DECADE-Enabled Vuze| 480MB | 12MB 774 | | | | 775 +--------------------+--------------------+--------------------+ 776 | | | | 777 | Native Vuze | 430MB | 430MB 778 | | | | 779 +--------------------+--------------------+--------------------+ 781 Figure 6 783 o 785 Higher system resource efficiency in the DECADE-Enabled Vuze 786 experiment, system resource efficiency is defined as the ratio of 787 system download rate to the total system bandwidth. The test 788 result is illustrated in the following figure. 790 | 791 | 792 | 88% 793 | 794 | +-------+ 795 | | | 796 | 65% | | 797 | | | 798 | +-------+ | | 799 | | | | | 800 | | | | | 801 | | | | | 802 | | | | | 803 | | | | | 804 | | | | | 805 | | | | | 806 | | | | | 807 | | | | | 808 | | | | | 809 +------+-------+---------+-------+-------- 810 Native Vuze DECADE-Enabled Vuze 812 Figure 7 814 8. Security Considerations 816 This document does not contain any security considerations. 818 9. IANA Considerations 820 This document does not have any IANA considerations. 822 10. Normative References 824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 825 Requirement Levels", BCP 14, RFC 2119, March 1997. 827 Authors' Addresses 829 Lijiang Chen 830 Yale University 832 Email: lijiang.chen@yale.edu 834 Hongqiang Liu 835 Yale University 837 Email: hongqiang.liu@yale.edu 839 Zhigang Huang 840 HUAWEI Technologies 842 Email: hpanda@huawei.com 844 Xiaohui Chen 845 HUAWEI Technologies 847 Email: chen.xiaohui@huawei.com