idnits 2.17.1 draft-ietf-decade-integration-example-00.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 2 instances of too long lines in the document, the longest one being 2 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 (April 29, 2011) is 4717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 461, 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: October 31, 2011 April 29, 2011 7 Leveraging In-network Storage in P2P LiveStreaming 8 draft-ietf-decade-integration-example-00 10 Abstract 12 DECADE is an in-network storage infrastructure which is under 13 discussions and constructions. It can be integrated into Peer-to- 14 Peer (P2P) applications to achieve more efficient content 15 distributions. This document represents a detailed example of how to 16 integrate DECADE into P2P live streaming (a popular P2P application). 17 Specifically, it describes mainly about: 1) a preliminary DECADE 18 client API; 2) a P2P live streaming integration with DECADE; 3) a 19 testing on our DECADE integrarion and 4) an application performance 20 analysis from the test. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on October 31, 2011. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. DECADE Module . . . . . . . . . . . . . . . . . . . . . . 3 66 2.3. P2P LiveStreaming Client (P2PLS Client) . . . . . . . . . 4 67 2.4. DECADE Client . . . . . . . . . . . . . . . . . . . . . . 4 68 3. DECADE Client API . . . . . . . . . . . . . . . . . . . . . . 4 69 4. DECADE Integration of P2P LiveStreaming Client . . . . . . . . 5 70 4.1. DECADE Integration Architecture . . . . . . . . . . . . . 5 71 4.1.1. Data Access . . . . . . . . . . . . . . . . . . . . . 5 72 4.1.2. Message Control . . . . . . . . . . . . . . . . . . . 6 73 4.2. Challenges in DECADE Integration . . . . . . . . . . . . . 6 74 4.2.1. Limited Connection Slot . . . . . . . . . . . . . . . 6 75 4.2.2. Additional Control Latency . . . . . . . . . . . . . . 7 76 5. Test Environment and Settings . . . . . . . . . . . . . . . . 7 77 5.1. Test Settings . . . . . . . . . . . . . . . . . . . . . . 8 78 5.2. Platforms and Components . . . . . . . . . . . . . . . . . 8 79 5.2.1. EC2 DECADE Server . . . . . . . . . . . . . . . . . . 9 80 5.2.2. PlanetLab P2P Live Streaming Client . . . . . . . . . 9 81 5.2.3. Tracker . . . . . . . . . . . . . . . . . . . . . . . 9 82 5.2.4. Source Server . . . . . . . . . . . . . . . . . . . . 9 83 5.2.5. Test Controller . . . . . . . . . . . . . . . . . . . 9 84 6. Performance Analysis . . . . . . . . . . . . . . . . . . . . . 9 85 6.1. Performance Metrics . . . . . . . . . . . . . . . . . . . 9 86 6.2. Result and Analysis . . . . . . . . . . . . . . . . . . . 10 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 DECADE is an in-network storage infrastructure under discussions and 95 constructions. It can be integrated into Peer-to-Peer (P2P) 96 applications to achieve more efficient content distributions. 98 This draft introduces an instance of application integration with 99 DECADE. In our example system, the core component includes DECADE 100 servers and DECADE-enabled P2P live streaming clients. A DECADE 101 server provides data storage and transport service with interactive 102 control to DECADE clients. We extended a P2P live streaming 103 application, P2PLS (P2P LiveStreaming), to leverage DECADE service 104 provided by the servers. P2PLS clients are DECADE-enabled. For our 105 implementation, we used a preliminary API (Application Programming 106 Interface) set, which is supposed to be provided by DECADE, to enable 107 P2PLS clients to use DECADE in their data transmission. In this 108 draft, we introduce the design of the DECADE-P2PLS integration 109 system, the main control flow for DECADE-enabled data transmission, 110 and the testing performance with this system. 112 Please note that P2PLS in this draft only represents the usage case 113 of "live streaming" out of a large number of P2P applications, while 114 DECADE itself can support other applications. The API set used in 115 this system is an experimental design and implementation. It is not 116 a standard and is still under development. Currently, DECADE in this 117 draft is only a preliminary framework of in-network storage for P2P. 118 It is designed to test the pros and cons of in-network storage 119 utilized by P2P applications rather than to reach a final solution. 121 2. Concepts 123 2.1. DECADE Server 125 A DECADE server is implemented with DECADE protocols, management 126 mechanism, and storage strategies. It is a core element to provide 127 DECADE service. Each DECADE server manages a number of Data Lockers, 128 each of which is a virtual account and corresponds to private storage 129 space for clients. 131 2.2. DECADE Module 133 DECADE module is a functional component for application clients to 134 utilize DECADE. This component serves as an application-specific 135 interface between a particular application and DECADE servers. It 136 can be a simple implementation of basic DECADE access APIs, or a more 137 intelligent integration, e.g. consider application-specific control 138 strategies when using DECADE APIs. 140 2.3. P2P LiveStreaming Client (P2PLS Client) 142 P2P LiveStreaming Client (P2PLS Client) is our self-maintained 143 version of a native P2P live streaming application. It is one 144 example out of a large number of P2P applications. 146 2.4. DECADE Client 148 DECADE client is an integration of a native P2PLS Client and a DECADE 149 module. It is not required to embed DECADE module into native P2P 150 clients, since it can also be an independent component running at a 151 remote server. 153 3. DECADE Client API 155 In order to simplify the DECADE integration with P2P clients, we 156 provide an API set which covers the communications with DECADE 157 servers and token-generation. On top of this API, a P2P client can 158 develop its own application-specific control and data distribution 159 policies. 161 There are five basic interfaces: 163 o Get_Object: to get an object from a DECADE server with an 164 authorized token. The get operation can be classified into two 165 categories: Local Get and Remote Get. Local Get is to get an 166 object from a local DECADE server. Remote Get is to use a 167 client's local DECADE server to indirectly get an object from a 168 remote DECADE server. The object will be firstly passed to the 169 local DECADE server, then returned to the application client 171 o Put_Object: to store an object into a DECADE server with an 172 authorized token. A client can either store an object into its 173 local DECADE server or into other clients' DECADE servers, if it 174 has an authorized token. Both of the operations are direct, for 175 we don't provide indirectly storing (i.e. remote put). 177 o Delete_Object: to delete an object in a DECADE server explicitly 178 with an authorized token. Note that an object can also be deleted 179 implicitly by setting an expired time or a specific TTL. 181 o Status_Query: to query current status of an application itself, 182 including listing stored objects, resource usage, etc.. Such 183 information is private. 185 o Generate_Token: to generate an authorized token. The token can be 186 used to access an application client's local DECADE server, or 187 passed to other clients to allow them to access the client's local 188 DECADE server. 190 4. DECADE Integration of P2P LiveStreaming Client 192 We integrate a DECADE module into a P2P live streaming application-- 193 P2PLS, in order that clients of this application can easily leverage 194 DECADE in their data distributions. 196 4.1. DECADE Integration Architecture 198 The architecture of the P2PLS application and DECADE integration is 199 shown in Figure 1: 201 +---------------+ +---------------+ 202 | DECADE | | DECADE | 203 | Peer | | Peer | 204 |+-------------+| +---------------+ |+-------------+| 205 ||DECADE Module||---| DECADE Server |---||DECADE Module|| 206 |+------^------+| +---------------+ |+------^------+| 207 | API | | | API | | 208 |+------v------+| +---------------+ |+------v------+| 209 ||Native Client||---| Tracker |---||Native Client|| 210 |+-------------+| +---------------+ |+-------------+| 211 +---------------+ +---------------+ 213 Figure 1 215 A DECADE-integrated P2PLS client uses DECADE client to communicate 216 with its DECADE server and transmit data between itself and its 217 DECADE server. It is compatible with its original P2P protocol, 218 while it also uses a DECADE protocol to exchange DECADE related 219 messages with other peers. 221 4.1.1. Data Access 223 DECADE module is called whenever a client wants to get data objects 224 from (or put data objects into) its DECADE server. Each data object 225 transferred between a client and its DECADE server should go through 226 DECADE module. Neither the DECADE server and the original client 227 knows each other. A data object is a data transfer unit between 228 DECADE servers and application clients. Its size can be application- 229 customized, according to variable requirements of performance or 230 sensitive factors (e.g. low latency, high bandwidth utilization). 232 4.1.2. Message Control 234 Control and data plane decoupling is a design principle of DECADE. 235 Control messages are propagated in an original P2P way. DECADE only 236 introduces an additional control message between DECADE module which 237 carries DECADE authorized token. By exchanging DECADE authorized 238 tokens, P2P live streaming clients can retrieve or store data objects 239 into or from others' DECADE servers. 241 4.2. Challenges in DECADE Integration 243 One essential objective of DECADE integration is to improve (or at 244 least not to hurt) the application performance. However, as a brand 245 new architecture, DECADE has some inherit challenges which will 246 potentially be harmful to application performance. In our P2P live 247 streaming case, we met mainly two such limitations of DECADE: 249 4.2.1. Limited Connection Slot 251 Limited Connection Slot: In native P2P systems, a peer can establish 252 tens or hunderds of concurrent connections with other peers. 253 However, this situation can hardly be ture when the application is 254 integrated with DECADE, because it is too expensive for a DECADE 255 server to maintain so many connections for each peer. Typically, 256 each DECADE peer only have m connection slots, which means it can 257 only at most have m active connections with its DECADE server 258 simultaneously. A potential "side effect" of limited connection slot 259 is that the content availability and downloading rate might be 260 impacted negatively by fewwer connections carrying data traffic. 261 This requests us to adjust the peer's behavior in resource 262 allocation, downloading/uploading scheduling, etc. to fully utilize 263 the connection slots to archieve a satisfying and robust data 264 downloading. 266 In our integration, we mainly employed two technical strategies: 268 o Batch Request: In order to fully utilize the connection bandwidth 269 of a DECADE server and reduce overhead, a P2PLS client may combine 270 multiple requests in a single request to DECADE server. Note that 271 for the sake of improving data transfer efficiency in P2P live 272 streaming, we may combine multiple data requests into a batch 273 request. Generally, a batch may consist of different kinds of 274 access requests. 276 o Larger Data Object Size: In typical P2P live streaming 277 application, the size of a data block is relatively small, 278 considering to reduce end-to-end transport latency. However, 279 existing data size may incur large control overhead and low 280 transport utilization. A larger data object size may be needed to 281 utilize DECADE more efficiently. 283 4.2.2. Additional Control Latency 285 Addtional Control Latency: In native P2P systems, when an uploader 286 decides to reply a request for a piece, it sends the piece out 287 directly. Nevertheless, in DECADE-aware P2P systems, the uploader 288 typically only replies with a token of the piece. And then the 289 downloader will leverage this token to fetch the piece from the 290 uploader's DECADE server. This process obviously introduces 291 additional control latency compared with native P2P systems. It is 292 even more serious in latency sensitive applications such as P2P live 293 streaming. We need to consider how to reduce such additional delay 294 or how to compensate the lose with other inherit advantages of 295 DECADE. 297 In our integration, we addressed this challenge by multiplexing 298 pieces into one token: 300 o Range Token: One way to reduce request latency is to use range 301 token. A P2PLS client may piggyback a range token when it 302 propagates its bitmap to its neighbors, to indicate that all 303 available pieces in the bitmap are accassable by this range token. 304 Then instead of requesting specific pieces from this client and 305 waiting for response, the neighbors can directly use this range 306 token to access data in DECADE servers. Note that this method not 307 only reduce request latency, but also reduce message overhead. 309 With these adjustments and strategies (it is not necessary to use 310 "Batch Request" and "Larger Object Size" both), DECADE clients' 311 performance was not impacted by the liminations of DECADE and was 312 even better than native clients' as we will see in following 313 sections. 315 5. Test Environment and Settings 317 In order to demonstrate the performance of our DECADE implementation 318 and DECADE-integrated P2P live streaming application, we conduct some 319 experimental tests in Amazon EC2 and PlanetLab. We perform a pair of 320 comparative experiments: DECADE integrated P2P live streaming v.s. 321 native P2P live streaming, in the same environment using the same 322 settings. 324 5.1. Test Settings 326 Our tests ran on a wide-spread area and diverse platforms, including 327 a famous commercial cloud platform, Amazon EC2 and a well-known test 328 bed, PlanetLab. The environment settings are as following: 330 o EC2 Regions: we setup DECADE servers in Amazon EC2 cloud, 331 including all four regions around the world, US east, US west, 332 Europe and Asia. 334 o PlanetLab: we run our P2P live streaming clients (both DECADE 335 integrated and native clients) on PlanetLab of a wild-spread area. 337 o Arrival pattern: we made all the clients join into the system 338 within a short duration to simulate a flash crowd scenario. 340 o Total Bandwidth: for a fair comparison, we set the system's total 341 supply bandwidth to be exact the same in both test. 343 5.2. Platforms and Components 345 In the tests, we have different functional components running in 346 different platforms, including DECADE servers, P2P live streaming 347 clients(DECADE integrated or Native), Tracker, Source server and Test 348 Controller, as shown in Figure 2. 350 +----------+ +------------+ +------------+ 351 | P2PLS | /| DECADE |----| DECADE | 352 | Manager | / | Server | | Server | 353 +--------^\+ / +-----|------+ +------|-----+ EC2 354 ___________\/_________|__________________|_______ 355 /\ | | 356 +---------/+ \ +-----|------+ +------|-----+ 357 | P2PLS ^ \ | P2PLS ^ ^ P2PLS | 358 | Source |\ \| Client |\ /| Client | 359 +-----|----+ \ \------^-----+ \/ +------^-----+ PlanetLab 360 ______|_______\__\_____|_______/\________|_______ 361 | \ \ | / \ | 362 +-----|----+ v--v---v-----v v------v-----+ 363 | Streaming| | P2PLS | | Test | 364 | Files | | Tracker | | Controller | 365 +----------+ +------------+ +------------+ Yale Lab 367 P2PLS represents to P2P Live Streaming. 369 Figure 2 371 5.2.1. EC2 DECADE Server 373 DECADE Servers ran on Amazon EC2 small instances, with bandwidth 374 constraint. 376 5.2.2. PlanetLab P2P Live Streaming Client 378 Both DECADE integrated and Native P2P live streaming clients ran on 379 PlanetLab which spreads in various locations around the world. The 380 DECADE integrated P2P live streaming clients connect to the closest 381 DECADE server according to its Geo-location distance to the servers. 382 DECADE integrated P2P live streaming clients use their DECADE servers 383 to upload to neighbors, instead of their own "last-mile" bandwidth. 385 5.2.3. Tracker 387 A native P2P live streaming tracker ran at Yale's laboratory and 388 served both DECADE integrated clients and native clients during the 389 test. 391 5.2.4. Source Server 393 A native P2P live streaming source server ran at Yale's laboratory 394 and serve both DECADE integrated clients and native clients during 395 the test. The capacity of source is equivalently constrain for both 396 cases. 398 5.2.5. Test Controller 400 Test Controller is a manager to control all machines' behaviors in 401 both EC2 and PlanetLab during the test. 403 6. Performance Analysis 405 During the test, DECADE integrated P2P live streaming clients 406 achieved an impressively better performance than native clients. 408 6.1. Performance Metrics 410 To measure the performance of a P2P live streaming client, we employ 411 mainly four metrics: 413 o Startup Delay: the duration from a peer joins the channel to the 414 moment it starts to play. 416 o Piece Missed Rate: the number of pieces a peer loses when playing 417 over the total number of pieces. 419 o Freeze Times: the number of times a peer re-buffers during 420 playing. 422 o Average Peer Uploading Rate: Average uploading bandwidth of a 423 peer. 425 6.2. Result and Analysis 427 o Startup Delay: In the test, DECADE integrated P2P live streaming 428 clients startup around 35~40 seconds. some of them startup at 429 about 10 seconds. Native P2P live streaming clients startup 430 around 110~120 seconds. less than 20% of them startup within 100 431 seconds. 433 o Piece Missed Rate: In the test, both DECADE integrated P2P live 434 streaming clients and native P2P live streaming clients achieved a 435 good performance in pieces missed rate. Only about 0.02% of total 436 pieces missed in both cases. 438 o Freeze Times: In the test, native P2P live streaming clients 439 suffered from more freezing than DECADE Integrated P2P live 440 streaming clients by 40%. 442 o Average Peer Uploading Rate: In the test, according to our 443 settings, DECADE integrated P2P live streaming clients had no 444 upload in their "last-mile" access network. While in the native 445 P2P live streaming system, more than 70% of peers uploaded in a 446 rate that is much more than streaming rate. In another word, 447 DECADE can shift uploading traffic from clients' "last-mile" to 448 in-network devices, which saves a lot of expensive bandwidth on 449 access links.. 451 7. Security Considerations 453 This document does not contain any security considerations. 455 8. IANA Considerations 457 This document does not have any IANA considerations. 459 9. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 Authors' Addresses 466 Lijiang Chen 467 Yale University 469 Email: lijiang.chen@yale.edu 471 Hongqiang Liu 472 Yale University 474 Email: hongqiang.liu@yale.edu