idnits 2.17.1 draft-song-decade-survey-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 12, 2010) is 5034 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.gu-decade-reqs' is defined on line 1169, but no explicit reference was found in the text == Unused Reference: 'HYAL08' is defined on line 1213, but no explicit reference was found in the text == Unused Reference: 'MCM08' is defined on line 1217, but no explicit reference was found in the text == Unused Reference: 'JZL08' is defined on line 1221, but no explicit reference was found in the text == Unused Reference: 'GYZ07' is defined on line 1226, but no explicit reference was found in the text == Unused Reference: 'JCL09' is defined on line 1231, but no explicit reference was found in the text == Unused Reference: 'GH09' is defined on line 1234, but no explicit reference was found in the text == Unused Reference: 'McGraw02' is defined on line 1237, but no explicit reference was found in the text == Unused Reference: 'OceanStore' is defined on line 1253, but no explicit reference was found in the text == Unused Reference: 'AVA09' is defined on line 1258, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-gu-decade-reqs-04 -- Obsolete informational reference (is this intentional?): RFC 3720 (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Alimi 3 Internet-Draft Yale University 4 Intended status: Informational Z. Lu 5 Expires: January 13, 2011 Fudan University 6 P. Tao 7 China Telecom 8 Y. Yang 9 Yale University 10 July 12, 2010 12 A Survey of In-network Storage Systems 13 draft-song-decade-survey-04 15 Abstract 17 This document describes existing in-network storage systems and their 18 applicability for DECADE. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 13, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Survey Overview . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Terminology and Concepts . . . . . . . . . . . . . . . . . 5 63 2.2. Historical Context . . . . . . . . . . . . . . . . . . . . 5 64 2.3. In-network Storage System Components . . . . . . . . . . . 7 65 2.3.1. Data Access Interface . . . . . . . . . . . . . . . . 7 66 2.3.2. Data Management Operations . . . . . . . . . . . . . . 7 67 2.3.3. Data Search Capability . . . . . . . . . . . . . . . . 7 68 2.3.4. Access Control Authorization . . . . . . . . . . . . . 7 69 2.3.5. Resource Control Interface . . . . . . . . . . . . . . 7 70 2.3.6. Discovery Mechanism . . . . . . . . . . . . . . . . . 8 71 2.3.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . 8 72 3. P2P Cache . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1. Transparent P2P Caches . . . . . . . . . . . . . . . . . . 8 74 3.1.1. Data Access Interface . . . . . . . . . . . . . . . . 9 75 3.1.2. Data Management Operations . . . . . . . . . . . . . . 9 76 3.1.3. Data Search Capability . . . . . . . . . . . . . . . . 9 77 3.1.4. Access Control Authorization . . . . . . . . . . . . . 9 78 3.1.5. Resource Control Interface . . . . . . . . . . . . . . 9 79 3.1.6. Discovery Mechanism . . . . . . . . . . . . . . . . . 9 80 3.1.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . 9 81 3.2. Non-transparent P2P Caches . . . . . . . . . . . . . . . . 9 82 3.2.1. Data Access Interface . . . . . . . . . . . . . . . . 9 83 3.2.2. Data Management Operations . . . . . . . . . . . . . . 10 84 3.2.3. Data Search Capability . . . . . . . . . . . . . . . . 10 85 3.2.4. Access Control Authorization . . . . . . . . . . . . . 10 86 3.2.5. Resource Control Interface . . . . . . . . . . . . . . 10 87 3.2.6. Discovery Mechanism . . . . . . . . . . . . . . . . . 10 88 3.2.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . 10 89 4. Web Cache . . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 4.1. Data Access Interface . . . . . . . . . . . . . . . . . . 11 91 4.2. Data Management Operations . . . . . . . . . . . . . . . . 11 92 4.3. Data Search Capability . . . . . . . . . . . . . . . . . . 11 93 4.4. Access Control Authorization . . . . . . . . . . . . . . . 11 94 4.5. Resource Control Interface . . . . . . . . . . . . . . . . 11 95 4.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 11 96 4.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 11 97 5. CDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 98 5.1. Data Access Interface . . . . . . . . . . . . . . . . . . 12 99 5.2. Data Management Operations . . . . . . . . . . . . . . . . 12 100 5.3. Data Search Capability . . . . . . . . . . . . . . . . . . 13 101 5.4. Access Control Authorization . . . . . . . . . . . . . . . 13 102 5.5. Resource Control Interface . . . . . . . . . . . . . . . . 13 103 5.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 13 104 5.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 13 105 5.8. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 13 106 6. NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 107 6.1. Data Access Interface . . . . . . . . . . . . . . . . . . 13 108 6.2. Data Management Operations . . . . . . . . . . . . . . . . 14 109 6.3. Data Search Capability . . . . . . . . . . . . . . . . . . 14 110 6.4. Access Control Authorization . . . . . . . . . . . . . . . 14 111 6.5. Resource Control Interface . . . . . . . . . . . . . . . . 14 112 6.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 14 113 6.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 14 114 6.8. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 14 115 7. WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 116 7.1. Data Access Interface . . . . . . . . . . . . . . . . . . 15 117 7.2. Data Management Operations . . . . . . . . . . . . . . . . 15 118 7.3. Data Search Capability . . . . . . . . . . . . . . . . . . 15 119 7.4. Access Control Authorization . . . . . . . . . . . . . . . 15 120 7.5. Resource Control Interface . . . . . . . . . . . . . . . . 16 121 7.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 16 122 7.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 16 123 7.8. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 16 124 8. iSCSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 125 8.1. Data Access Interface . . . . . . . . . . . . . . . . . . 17 126 8.2. Data Management Operations . . . . . . . . . . . . . . . . 17 127 8.3. Data Search Capability . . . . . . . . . . . . . . . . . . 17 128 8.4. Access Control Authorization . . . . . . . . . . . . . . . 17 129 8.5. Resource Control Interface . . . . . . . . . . . . . . . . 17 130 8.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 17 131 8.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 17 132 9. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 133 9.1. Data Access Interface . . . . . . . . . . . . . . . . . . 18 134 9.2. Data Management Operations . . . . . . . . . . . . . . . . 18 135 9.3. Data Search Capability . . . . . . . . . . . . . . . . . . 18 136 9.4. Access Control Authorization . . . . . . . . . . . . . . . 18 137 9.5. Resource Control Interface . . . . . . . . . . . . . . . . 18 138 9.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 18 139 9.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 19 140 9.8. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 19 141 10. Amazon S3 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 142 10.1. Data Access Interface . . . . . . . . . . . . . . . . . . 19 143 10.2. Data Management Operations . . . . . . . . . . . . . . . . 19 144 10.3. Data Search Capability . . . . . . . . . . . . . . . . . . 19 145 10.4. Access Control Authorization . . . . . . . . . . . . . . . 19 146 10.5. Resource Control Interface . . . . . . . . . . . . . . . . 19 147 10.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 20 148 10.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 20 149 11. OceanStore . . . . . . . . . . . . . . . . . . . . . . . . . . 20 150 11.1. Data Access Interface . . . . . . . . . . . . . . . . . . 20 151 11.2. Data Management Operations . . . . . . . . . . . . . . . . 20 152 11.3. Data Search Capability . . . . . . . . . . . . . . . . . . 20 153 11.4. Access Control Authorization . . . . . . . . . . . . . . . 20 154 11.5. Resource Control Interface . . . . . . . . . . . . . . . . 20 155 11.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 21 156 11.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 21 157 12. Cache-and-Forward Architecture . . . . . . . . . . . . . . . . 21 158 12.1. Data Access Interface . . . . . . . . . . . . . . . . . . 21 159 12.2. Data Management Operations . . . . . . . . . . . . . . . . 21 160 12.3. Data Search Capability . . . . . . . . . . . . . . . . . . 21 161 12.4. Access Control Authorization . . . . . . . . . . . . . . . 21 162 12.5. Resource Control Interface . . . . . . . . . . . . . . . . 21 163 12.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 21 164 12.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 22 165 13. Network Traffic Redundancy Elimination . . . . . . . . . . . . 22 166 13.1. Data Access Interface . . . . . . . . . . . . . . . . . . 22 167 13.2. Data Management Operations . . . . . . . . . . . . . . . . 22 168 13.3. Data Search Capability . . . . . . . . . . . . . . . . . . 22 169 13.4. Access Control Authorization . . . . . . . . . . . . . . . 22 170 13.5. Resource Control Interface . . . . . . . . . . . . . . . . 23 171 13.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 23 172 13.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 23 173 14. BranchCache . . . . . . . . . . . . . . . . . . . . . . . . . 23 174 14.1. Data Access Interface . . . . . . . . . . . . . . . . . . 24 175 14.2. Data Management Operations . . . . . . . . . . . . . . . . 24 176 14.3. Data Search Capability . . . . . . . . . . . . . . . . . . 24 177 14.4. Access Control Authorization . . . . . . . . . . . . . . . 24 178 14.5. Resource Control Interface . . . . . . . . . . . . . . . . 24 179 14.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 25 180 14.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 25 181 15. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 182 16. Security Considerations . . . . . . . . . . . . . . . . . . . 25 183 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 184 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 185 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 186 19.1. Normative References . . . . . . . . . . . . . . . . . . . 26 187 19.2. Informative References . . . . . . . . . . . . . . . . . . 26 188 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 190 1. Introduction 192 DECADE (DECoupled Application Data Enroute) is an architecture that 193 provides applications with access to in-network storage. 195 A major motivation for DECADE is the substantial increase on capacity 196 and reduction in cost offered by storage systems. In particular, 197 over the last decade, capacity of solid-state storage has increased 198 100-fold, while cost dropped to $50/GB; capacity of magnetic storage 199 devices has increased 100-fold, while cost dropped to $0.50/GB. 201 High-capacity and low-cost in-network storage devices introduce 202 substantial opportunities. One example of in-network storage is 203 content caches supporting Web and P2P content. Different from 204 existing content caches whose control fully reside at the owners of 205 the caching devices, DECADE also allows applications to control 206 access to their allocated in-network storage, as well as the 207 resources consumed while accessing that storage (bandwidth, 208 connections, storage space). While designed in the context of P2P 209 applications, it may be useful to other applications as well. This 210 document provides details on existing in-network storage solutions, 211 and evaluates their suitability for DECADE. 213 We note that the techniques presented in this section are only 214 representative of the research in this area. Rather than trying to 215 enumerate an exhaustive list, we have chosen some typical techniques 216 that lead to derivative works. 218 2. Survey Overview 220 2.1. Terminology and Concepts 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in [RFC2119]. 226 This document uses terms defined in 227 [I-D.song-decade-problem-statement]. 229 2.2. Historical Context 231 In-network storage has been used previously in numerous scenarios to 232 reducing network traffic and enable more efficient content 233 distribution. Systems have been developed with particular use cases 234 in mind. Thus, this survey is not meant to point out shortcomings of 235 existing solutions, but rather to indicate where certain capabilities 236 required in DECADE are not provided by existing systems. 238 In the early stage of Internet development, most Web content was 239 stored at a central server and clients requested Web content from the 240 central server. In this architecture, the central server was 241 required to provide a large amount of bandwidth. Web browsing is 242 still a primary activity on today's Internet. As more and more users 243 access Web content, a central server can become overloaded. The use 244 of web caches is one technique to reduce load on a central server. 245 Web caches store frequently-requested content, and provide bandwidth 246 for serving the content to clients. 248 The ongoing growth of broadband technology in the worldwide market 249 has been driven by the hunger of customers for new multimedia 250 services as well as Web content. In particular, the use of audio and 251 video streaming formats has become common for delivery of rich 252 information to the public - both residential and business. 254 To overcome this challenge of massive multimedia consumption, only 255 installing more Web cache will not be enough. Moving content closer 256 to the consumer results in greater network efficiency, improved QoS, 257 and lower latency, while facilitating personalization of content 258 through broadband content applications. In these edge technologies, 259 CDN is a representative technique. Content Delivery Networks (CDN) 260 is based on a large-scale distributed network of servers located 261 closer to the edges of the Internet for efficient delivery of digital 262 content including various forms of multimedia content. 264 Although CDN is an effective means of information access and 265 delivery, there are two barriers to making CDN a more common service: 266 cost and replication integrity. Deploying a CDN for publicly 267 available content is expensive. It requires administrative control 268 over nodes with large storage capacity at geographically dispersed 269 locations with adequate connectivity. CDN can be scalable, but due 270 to this administrative and cost overhead, not rapidly deployable for 271 the common user. 273 The emergence and maturity of Peer to Peer (P2P) has allowed 274 improvements to many network applications. P2P allows the use of 275 client resources, such as CPU, memory, storage, and bandwidth, for 276 serving content. This can reduce the amount of resources required by 277 a content provider. Multimedia content delivery using various peer- 278 to-peer or peer-assisted frameworks has been shown to greatly reduce 279 the dependence on CDN and central content servers. However, 280 popularity of P2P applications has resulted in increased traffic on 281 ISP networks. 283 DECADE aims to provide a standard protocol allowing P2P applications 284 (including Content Providers) to make use of in-network storage to 285 reduce the traffic burden on ISP networks, while enabling P2P 286 applications to control access to content they have placed in in- 287 network storage. 289 2.3. In-network Storage System Components 291 Before surveying individual technologies, we describe the basic 292 components of in-network storage systems used to evaluate them in the 293 context of DECADE. 295 Note that the network protocol(s) used by a storage system are also 296 an important part of the design. We omit details of particular 297 protocol choices in the current version of this document. 299 2.3.1. Data Access Interface 301 A set of operations are available to a user for accessing data in the 302 in-network storage. Solutions typically allow both read and write, 303 though the mechanisms for doing so can differ drastically. 305 2.3.2. Data Management Operations 307 Storage systems may provide users the ability to manage stored 308 content. For example, operations such as delete and move can be 309 provided to users. In this survey, we focus on data management 310 operations that are provided to client users and omit those provided 311 to system administrators. 313 2.3.3. Data Search Capability 315 Some storage systems may provide the capability to search or 316 enumerate content that has been stored. In this survey, we focus on 317 search capabilities that are provided to client users and omit those 318 provided to system administrators. 320 2.3.4. Access Control Authorization 322 A user is able to authorize individual users to retrieve the content 323 stored on its In-network storage. In-network storage can check the 324 authorization of a client before it stores or retrieves content. In- 325 network storage only permits the users with authorization to access 326 the corresponding contents. The admission could be based on user, 327 content, time period, etc. 329 2.3.5. Resource Control Interface 331 This is the interface through which users manage the resources on in- 332 network storage that can be used by other peers, e.g., the bandwidth 333 or connections. The storage system may also allow users to indicate 334 a time for which resources are granted. 336 2.3.6. Discovery Mechanism 338 Users use the discovery mechanism to find location of in-network 339 storage, find access interface or resource control interface or other 340 interfaces of in-network storage. 342 2.3.7. Storage Mode 344 The data managed by the in-network storage could be of various types. 345 Example storage modes are file-based, object-based, or block-based. 347 3. P2P Cache 349 Caching of P2P traffic is a useful approach to reduce P2P network 350 traffic, because objects in P2P systems are mostly immutable and the 351 traffic is highly repetitive . In addition, making use of P2P caches 352 do not require changes to P2P protocols and can be deployed 353 transparently from clients. 355 P2P caches operate similarly to web caches, in that they temporarily 356 store frequently-requested content. Requests for content already 357 stored in the cache can be served from local storage instead of 358 requiring the data to be transmitted over expensive network links. 360 Two types of P2P caches exist: non-transparent P2P caches and 361 transparent P2P caches. A non-transparent cache appears as a super 362 peer; it explicitly peers with other P2P clients. For a transparent 363 cache, once a P2P cache is established, the network will 364 transparently redirect P2P traffic to the cache, which either serves 365 the file directly or passes the request on to a remote P2P user and 366 simultaneously caches that data. Transparency is typically 367 implemented using deep packet inspection (DPI). DPI products 368 identify and pass P2P packets to the P2P caching system so it can 369 cache the traffic and accelerate it. 371 To enable operation with existing P2P software, P2P caches directly 372 support P2P application protocols. A large number of P2P protocols 373 are used by P2P software, and hence are supported by caches, leading 374 to higher complexity. Additionally, these protocols evolve over 375 time, and new protocols are introduced. 377 3.1. Transparent P2P Caches 378 3.1.1. Data Access Interface 380 Data Access Interface allows P2P content to be cached (stored) and 381 supplied (retrieved) locally such that network traffic is reduced, 382 but it is transparent to P2P users, and P2P users implicitly use the 383 data-access interface (in the form of their native P2P application 384 protocol) to store or retrieve content. 386 3.1.2. Data Management Operations 388 Not provided. 390 3.1.3. Data Search Capability 392 Not provided. 394 3.1.4. Access Control Authorization 396 Not provided. 398 3.1.5. Resource Control Interface 400 Not provided. 402 3.1.6. Discovery Mechanism 404 Use of Deep Packet Inspection means no discovery mechanism provided 405 to P2P users, it is transparent to P2P users. Since DPI is used to 406 recognize P2P applications private protocols, P2P Cache is getting 407 more and more complicated as the P2P applications keep evolving. 409 3.1.7. Storage Mode 411 Object-based. Chunks (typically, the unit of transfer amongst P2P 412 clients) of content are stored in the cache. 414 3.2. Non-transparent P2P Caches 416 3.2.1. Data Access Interface 418 Data Access Interface allows P2P content to be cached (stored) and 419 supplied (retrieved) locally such that network traffic is reduced. 420 P2P users implicitly store and retrieve from the cache using the P2P 421 application's native protocol. 423 3.2.2. Data Management Operations 425 Not provided. 427 3.2.3. Data Search Capability 429 Not provided. 431 3.2.4. Access Control Authorization 433 Not provided. 435 3.2.5. Resource Control Interface 437 Not provided. 439 3.2.6. Discovery Mechanism 441 Cache pretends to be normal peers to join the P2P overlay network. 442 Other P2P users can find these cache nodes through overlay routing 443 mechanism, just looking them as normal neighbor nodes. 445 3.2.7. Storage Mode 447 Object-based. Chunks (typically, the unit of transfer amongst P2P 448 clients) of content are stored in the cache. 450 4. Web Cache 452 Web cache is a well-built technology since the late 1990s, which has 453 been widely deployed by many ISPs to reduce bandwidth consumption and 454 web access latency. A web cache can cache the web documents (e.g., 455 HTML pages, images) between server and client to reduce bandwidth 456 usage, server load, and perceived lag. A web cache server is 457 typically shared by many clients, and stores copies of documents 458 passing through it; subsequent requests may be satisfied from the 459 cache if certain conditions are met. 461 Another form of cache is a client-side cache, typically implemented 462 in web browsers. A client side cache can keep a local copy of all 463 pages recently displayed by browser, and when the user returns to one 464 of these web pages, the local cached copy is reused. 466 A related protocol for P2P applications to use web cache is HPTP 467 (HTTP based Peer to Peer). It proposes to share chunks of P2P files/ 468 streams using HTTP protocol with cache-control headers. 470 4.1. Data Access Interface 472 Users explicitly read from a web cache by making requests, but they 473 cannot explicitly write data into it. Data is implicitly stored into 474 the web cache by requesting content that not already cached and meets 475 policy restrictions of the cache provider. 477 4.2. Data Management Operations 479 Not provided. 481 4.3. Data Search Capability 483 Not provided. 485 4.4. Access Control Authorization 487 Not provided. 489 4.5. Resource Control Interface 491 Not provided. 493 4.6. Discovery Mechanism 495 Web Caches can be transparently deployed between Web Server and Web 496 Clients, employing DPI for discovery. Alternatively, web caches 497 could be explicitly discovered by clients using techniques such as 498 DNS or manual configuration. 500 4.7. Storage Mode 502 Object based. Web content is keyed within the cache by HTTP Request 503 fields, such as Method, URI, and Headers. 505 5. CDN 507 Pathan et al. introduced the main idea and function of Content 508 Delivery Networks (CDN) [PR07]. CDN provides services that improve 509 network performance by maximizing bandwidth, improving accessibility 510 and maintaining correctness through content replication. They offer 511 fast and reliable applications and services by distributing content 512 to cache or edge servers located close to users. 514 A CDN has some combination of content-delivery, request-routing, 515 distribution and accounting infrastructure. The content-delivery 516 infrastructure consists of a set of edge servers (also called 517 surrogates) that deliver copies of content to end-users. The 518 request-routing infrastructure is responsible to directing client 519 request to appropriate edge servers. It also interacts with the 520 distribution infrastructure to keep an up-to-date view of the content 521 stored in the CDN caches. The distribution infrastructure moves 522 content from the origin server to the CDN edge servers and ensures 523 consistency of content in the caches. The accounting infrastructure 524 maintains logs of client accesses and records the usage of the CDN 525 servers. This information is used for traffic reporting and usage- 526 based billing. 528 In practice, CDN typically host static content including images, 529 video, media clips, advertisements, and other embedded objects for 530 dynamic Web content. A focus for CDNs is the ability to publish and 531 deliver content to end-users in a reliable and timely manner. A CDN 532 focuses on building its network infrastructure to provide the 533 following services and functionalities: storage and management of 534 content; distribution of content among surrogates; cache management; 535 delivery of static, dynamic and streaming content; backup and 536 disaster recovery solutions; and monitoring, performance measurement 537 and reporting. 539 Examples of existing CDNs are Akamai, Limelight, and CloudFront. 541 The following description uses the term Content Provider to refer to 542 the entity purchasing CDN service, and the term Client to refer to 543 the subscriber requesting content via the CDN from the Content 544 Provider. 546 5.1. Data Access Interface 548 CDN is typically an internal closed system, and CDN just provide read 549 (retrieve) access interface to clients but they don't provide 550 write(store) access interface to clients. Content provider can 551 access to network edge servers and store content to them, or edge 552 servers retrieve content from content provider, but client nodes just 553 can retrieve content from edge servers. 555 5.2. Data Management Operations 557 Content Provider can manage the data distributed in different cache 558 nodes, such as moving one hot data from one cache node to another 559 cache node, or deleting one rarely-accessed data in one cache node, 560 but client user nodes have no right to perform these operations. 562 5.3. Data Search Capability 564 Content provider can search or enumerate what data each cache node 565 hold, but client user nodes have no right to perform these 566 operations. 568 5.4. Access Control Authorization 570 Content Providers typically cannot control per-client access to 571 content accessed via a CDN. 573 5.5. Resource Control Interface 575 Not provided. 577 5.6. Discovery Mechanism 579 Content providers can directly find internal CDN cache nodes to store 580 content, since they typically have an explicit business relationship. 581 Clients can locate CDN nodes through DNS or other redirection 582 mechanism. 584 5.7. Storage Mode 586 A file-based storage mode is typically used. In most cases, CDN 587 cache nodes cache the entire file from content provider, and 588 sometimes they also can only cache some objects, such as file prefix 589 or file suffix. 591 5.8. Comments 593 6. NFS 595 The Network File System is designed to allow users to access files 596 over a network in a manner similar to how local storage is accessed. 597 NFS is typically used in local area network or enterprise settings, 598 though changes made in later versions of NFS make it easier to 599 operate over the Internet. 601 6.1. Data Access Interface 603 Traditional file-system operations such as read, write, and update 604 (overwrite) are provided. Locking is provided to support concurrent 605 access by multiple clients. 607 6.2. Data Management Operations 609 Traditional file-system operations such as move and delete are 610 provided. 612 6.3. Data Search Capability 614 User has the ability to list contents of directories to find 615 filenames matching desired criteria. 617 6.4. Access Control Authorization 619 Files and directories can be protected using read, write, and execute 620 permissions for the files owner, group, and the public (others). 621 Also, NFSv4.1 has a rich ACL model allowing a list of Access Control 622 Entries (ACEs) to be configured for each file or directory. The ACEs 623 can specify per-user read/write access to file data, file/directory 624 attributes, creation/deletion of files in a directory, etc. 626 6.5. Resource Control Interface 628 While disk space quotas can be configured, it typically limits the 629 total amount of storage allocated to a particular user. User control 630 of bandwidth and connections used by remote peers is not provided. 632 6.6. Discovery Mechanism 634 Manual configuration is typically used. Clients address NFS servers 635 by providing a hostname and a directory that should be mounted. 637 6.7. Storage Mode 639 File-based storage, allowing files to be organized into directories. 641 6.8. Comments 643 The efficiency and scalability of the NFS access control method is a 644 concern in the context of DECADE. In particular, Section 6.2.1 of 645 [RFC5661] states that: 647 Only ACEs that have a "who" that matches the requester 648 are considered. 650 Thus, in the context of DECADE, to specify per-peer access control 651 policies for an object, a client would need to explicitly configure 652 the ACL for the object for each individual peer. A concern with this 653 approach is scalability when a client's peers may change frequently 654 and ACLs for many small objects need to be updated constantly during 655 participation in a swarm. 657 Note that NFS v4.1's usage of RPCSEC_GSS provides support for 658 multiple security mechanisms. Kerberos V5 is required, but others 659 such as X.509 Certificates are also supported by way of GSS-API. 660 Note, however, that NFSv4.1's usage of such security mechanisms is 661 limited to linking a requesting user to a particular account 662 maintained by the NFS server. 664 7. WebDAV 666 WebDAV [RFC4918] is a protocol designed for Web content authoring. 667 It is developed as an extension to HTTP/1.1, meaning it can be 668 simpler to integrate into existing software. WebDAV supports 669 traditional operations for reading/writing from storage, as well as 670 other constructs such as locking and collections which are important 671 when multiple users collaborate to author or edit a set of documents. 673 7.1. Data Access Interface 675 Traditional read and write operations are supported (using HTTP GET 676 and PUT methods, respectively). Locking is provided to ease 677 concurrent access by multiple clients. 679 7.2. Data Management Operations 681 WebDAV supports traditional file-system operations such as move, 682 delete and copy. Objects are organized into collections, and these 683 operations can also be performed on collections. WebDAV also allows 684 objects to have user-defined properties. 686 7.3. Data Search Capability 688 User has the ability to list contents of collections to find objects 689 matching desired criteria. A SEARCH extension [RFC5323] has also 690 been specified allowing listing of objects matching client-defined 691 criteria. 693 7.4. Access Control Authorization 695 An ACL extension [RFC3744] is provided for WebDAV. ACLs allow both 696 user- and group-based access control policies (relating to reading, 697 writing, properties, locking, etc) to be defined for objects and 698 collections. 700 A ticketing extension [I-D.ito-dav-ticket] has also been proposed, 701 but has not progressed passed an Internet Draft. This extension 702 allows a client to request the WebDAV server to create a "ticket" 703 (e.g., for reading an object) that can be distributed to other 704 clients. Tickets may be given expiration times, or may only allow 705 for a fixed number of uses. The proposed extension requires the 706 server to generate tickets and maintain state for outstanding 707 tickets. 709 7.5. Resource Control Interface 711 An extension [RFC4331] allows disk space quotas to be configured for 712 Collections. The extension also allows WebDAV clients to query 713 current disk space usage. User control of bandwidth and connections 714 used by remote peers is not provided. 716 7.6. Discovery Mechanism 718 Manual configuration is typically used. Clients address WebDAV 719 servers by providing a hostname. 721 7.7. Storage Mode 723 File-based storage (a non-collection resource can typically be 724 thought of as a "file"). Files may be organized into collections, 725 which typically map on to the HTTP Path hierarchy. 727 7.8. Comments 729 The efficiency and scalability of the WebDAV access control method is 730 a concern in the context of DECADE, for similar reasons as stated in 731 Section 6.8 for NFS. The proposed WebDAV ticketing extension 732 partially alleviates this concern, but the particular technique may 733 need further evaluation before being applied to DECADE. In 734 particular, since DECADE clients may continuously upload/download a 735 large number of small-size objects, and a single DECADE server may 736 need to scale to many concurrent DECADE clients, requiring the server 737 to maintain ticket state and generate tickets may not be the best 738 design choice. Server-generated tickets can also increase latency 739 for data transport operations depending on the message flow used by 740 DECADE. 742 8. iSCSI 744 SCSI is a set of protocols enabling communication with storage 745 devices such as disk drives and tapes; iSCSI [RFC3720] is a protocol 746 enabling SCSI commands to be sent over TCP. As in SCSI, iSCSI allows 747 an Initiator to send commands to a Target. These commands operate on 748 the device level as opposed to individual data objects stored on the 749 device. 751 8.1. Data Access Interface 753 Read and write commands indicate which data is to be read or written 754 by specifying the offset (using Logical Block Addressing) into the 755 storage device. The size of data to be read or written is an 756 additional parameter in the command. 758 8.2. Data Management Operations 760 Since commands operate at the device level, management operations are 761 different than with traditional file systems. Management commands 762 for SCSI/iSCSI including explicit device control such as starting and 763 stopping the device and formatting the device. 765 8.3. Data Search Capability 767 SCSI/iSCSI does not provide the ability to search for particular data 768 within a device. Note that such capabilities can be implemented 769 outside of iSCSI. 771 8.4. Access Control Authorization 773 Since SCSI/iSCSI operates at the device level, neither authentication 774 nor authorization are provided for individual data objects. However, 775 iSCSI does use CHAP [RFC1994] to authenticate initiators and targets 776 when accessing storage devices. Note that such capabilities can be 777 implemented outside of iSCSI. 779 8.5. Resource Control Interface 781 Not provided. 783 8.6. Discovery Mechanism 785 Manual configuration may be used. An alternative is the Internet 786 Storage Name Service (iSNS) [RFC4171] provides the ability to 787 discover available storage resources. 789 8.7. Storage Mode 791 Block-based. SCSI/iSCSI provides an Initiator block-level access to 792 the storage device. 794 9. OAuth 796 OAuth [I-D.hammer-oauth] is a protocol that richens the traditional 797 client-server authentication model for web resources. In particular, 798 OAuth distinguishes the "client" from the "resource owner", thus 799 enabling a resource owner to authorize a particular client for access 800 (e.g., for a particular lifetime) to private resources. 802 Note that OAuth is a protocol for authentication and purposefully 803 does not itself provide access to network storage. We include it in 804 the survey so that its authentication model can be evaluated in the 805 context of DECADE. 807 9.1. Data Access Interface 809 Not applicable. 811 9.2. Data Management Operations 813 Not applicable. 815 9.3. Data Search Capability 817 Not applicable. 819 9.4. Access Control Authorization 821 While similar in spirit to the WebDAV ticketing extensions 822 [I-D.ito-dav-ticket], OAuth instead uses the following process: (1) a 823 client constructs a delegation request, (2) the client forwards the 824 request to the resource owner for authorization, (3) the resource 825 owner authorizes the request, and finally (4) a callback is made to 826 the client indicating that its request has been authorized. 828 Once the process is complete, the client has a set of token 829 credentials that grant it access to the protected resource. The 830 token credentials may have an expiration time, and they can also be 831 revoked by the resource owner at any time. 833 9.5. Resource Control Interface 835 Not applicable. 837 9.6. Discovery Mechanism 839 Not applicable. 841 9.7. Storage Mode 843 Not applicable. 845 9.8. Comments 847 The ticketing mechanism requires server involvement and the 848 discussion relating to WebDAV's proposed ticketing mechanism (see 849 Section 7.8) applies here as well. 851 10. Amazon S3 853 Amazon S3 [AmazonS3] provides an online storage service. Users 854 create buckets, and each bucket can contain stored objects. Users 855 are provided an interface through which they can manage their 856 buckets. Amazon S3 is popular backend storage for other services. 857 Another related storage service is the Blob Service provided by 858 Windows Azure [Azure]. 860 10.1. Data Access Interface 862 Users can read, and write objects. 864 10.2. Data Management Operations 866 Users can delete previously-stored objects. 868 10.3. Data Search Capability 870 Users can list contents of buckets to find objects matching desired 871 criteria. 873 10.4. Access Control Authorization 875 Access to stored objects can be restricted by owner, a list of other 876 Amazon Web Service users, all Amazon Web Service Users, or open to 877 all users (anonymous access). Another option is for the owner to 878 generate and sign a query (e.g., a query to read an object) that can 879 be used by any user until an owner-defined expiration time. 881 10.5. Resource Control Interface 883 Not provided. 885 10.6. Discovery Mechanism 887 Users are provided a well-known DNS name (either a default provided 888 by Amazon, or one customized by a particular user). Users accessing 889 S3 storage use DNS to discover an IP address where S3 requests can be 890 sent. 892 10.7. Storage Mode 894 Object-based, with the extension that objects can be organized into 895 user-defined buckets. 897 11. OceanStore 899 OceanStore is a storage platform developed at UC Berkeley that 900 provides globally-distributed storage. OceanStore implements a model 901 where multiple storage providers can pool resources together. Thus, 902 a major focus is on resiliency and self-organization and self- 903 maintenance. 905 The protocol is resilient to some storage nodes being compromised by 906 utilizing Byzantine agreement and erasure codes to store data at 907 primary replicas. 909 11.1. Data Access Interface 911 Users may read and write objects 913 11.2. Data Management Operations 915 Objects may be replaced by newer versions, and multiple versions of 916 an object may be maintained. 918 11.3. Data Search Capability 920 Not provided. 922 11.4. Access Control Authorization 924 Provided, but specifics are unclear from published paper. 926 11.5. Resource Control Interface 928 Not provided. 930 11.6. Discovery Mechanism 932 Users require an entry-point into the system in the form of one 933 storage node that is part of OceanStore. 935 11.7. Storage Mode 937 Object-based, though interfaces have been provided for NFS and HTTP. 939 12. Cache-and-Forward Architecture 941 Cache-and-Forward [PRDW08] is an architecture content delivery 942 services in the future Internet. In this architecture, storage can 943 be exploited at nodes with the network, either directly at routers or 944 deployed nearby routers. CNF is based on the concept of store-and- 945 forward routers with large storage, providing for opportunistic 946 delivery to occasionally disconnected mobile users and for in-network 947 caching of content. The proposed CNF protocol uses reliable hop-by- 948 hop transfer of large data files between CNF routers in place of an 949 end-to-end transport protocol like TCP. 951 12.1. Data Access Interface 953 Users implicitly store content at Cache-and-forward routers by 954 requesting files. End hosts read content from in-network storage by 955 submitting queries for content. 957 12.2. Data Management Operations 959 Not provided. 961 12.3. Data Search Capability 963 Not provided. 965 12.4. Access Control Authorization 967 Not provided. 969 12.5. Resource Control Interface 971 Not provided. 973 12.6. Discovery Mechanism 975 A query including a location-independent content ID is sent to the 976 network, and routed to a Cache-and-forward router, which handles 977 retrieval of the data and forwarding to the end host. 979 12.7. Storage Mode 981 Object-based (with objects representing individual files). The 982 architecture proposes to cache large files at storage within the 983 network, though files could be made to represent smaller chunks of 984 larger files. 986 13. Network Traffic Redundancy Elimination 988 Another form of in-network storage is Redundancy Elimination (RE), or 989 identifying and removing repeated content from network transfers. 990 This technique has been proposed to improve network performance in 991 many types of networks, such as ISP backbones and enterprise access 992 links. One example redundancy elimination proposal is SmartRE, 993 proposed by Anand et al., which focuses on network-wide redundancy 994 elimination. In packet-level redundancy elimination, forwarding 995 elements are equipped with additional storage which can be used to 996 cache data from forwarded packets. Upstream routers may replace 997 packet data with a fingerprint that tells a downstream router how to 998 decode and reconstruct the packet based on cached data. 1000 13.1. Data Access Interface 1002 Redundancy-elimination are typically transparent to the user. 1003 Writing into the storage is done by transferring data that has not 1004 already been cached. Storage is read when users transmit data 1005 identical to previously-transmitted data. 1007 13.2. Data Management Operations 1009 Not provided. 1011 13.3. Data Search Capability 1013 Not provided. 1015 13.4. Access Control Authorization 1017 Not provided. However, note that the content provider still retains 1018 control over which peers receive the requested data. The returned 1019 data is simple "compressed" as it is transferred within the network. 1021 13.5. Resource Control Interface 1023 Not provided. The content provider still retains control over the 1024 rate at which packets are sent to a peer. The packet size within the 1025 network may be reduced. 1027 13.6. Discovery Mechanism 1029 No discovery mechanism is necessary. Routers can use redundancy- 1030 elimination without the users' knowledge. 1032 13.7. Storage Mode 1034 Object-based, with "objects" being data from packets transmitted 1035 within the network. 1037 14. BranchCache 1039 BranchCache [BranchCache] is a feature integrated into Windows 1040 (Windows 7 and Windows Server 2008R2) that aims to optimize 1041 enterprise branch office file access over the WAN links. The main 1042 goals are to reduce WAN link utilization and improve application 1043 responsiveness by caching and sharing content within a branch while 1044 still maintaining end-to-end security. BranchCache allows files 1045 retrieved from the web servers and file servers located in 1046 headquarters or datacenters to be cached in remote branch offices, 1047 and shared among users in the same branch accessing the same content. 1048 BranchCache operates transparently by instrumenting the HTTP and SMB 1049 components of the networking stack. It provides two modes of 1050 operation: Distributed Cache and Hosted Cache. 1052 In both modes, a client always contacts a BranchCache-enabled content 1053 server first to get the content identifiers for local search. If the 1054 content is cached locally, the client then retrieves the content 1055 within the branch. Otherwise, the client will go back to the 1056 original content server to request the content. The two modes differ 1057 in how the content is shared. 1059 In the Hosted Cache mode, a locally provisioned server acts as a 1060 cache for files retrieved from the servers. After getting the 1061 content identifiers, the client first consults the cache for the 1062 desired file. If it is not present in the cache, the client 1063 retrieves it from the content server and sends it to the cache for 1064 storage. 1066 In the Distributed Cache mode, a client first queries other clients 1067 in the same network using the Web Services Discovery multicast 1068 protocol. As in the Hosted Cache mode, the client retrieves the file 1069 from the content server it is not available locally. After 1070 retrieving the file (either from another client or the content 1071 server), the client stores the file locally. 1073 The original content server always authorizes requests from clients. 1074 Cached content is encrypted, and clients can only decrypt the data 1075 using keys derived from metadata returned by the content server. In 1076 addition to instrumenting the networking stack at clients, content 1077 servers must also support BranchCache. 1079 14.1. Data Access Interface 1081 Clients transparently retrieve (read) data from a cache (other 1082 clients or a Hosted Cache) since it operates by instrumenting the 1083 networking stack. In Hosted Cache mode, clients write data to the 1084 Hosted Cache once it is retrieved from the content server. 1086 14.2. Data Management Operations 1088 Not provided. 1090 14.3. Data Search Capability 1092 Not provided. 1094 14.4. Access Control Authorization 1096 Transferred content is encrypted, and can only be decrypted by keys 1097 derived from data received from the original content server. Though 1098 data may be transferred to unauthorized clients, end-to-end security 1099 is maintained by only allowing authorized clients to decrypt the 1100 data. 1102 14.5. Resource Control Interface 1104 The storage capacity of caches on the clients and Hosted Caches are 1105 configurable by system administrators. The Hosted Cache further 1106 allows configuration of the maximum number of simultaneous client 1107 accesses. In the Distributed Caching mode, exponential back-off and 1108 throttling mechanisms are utilized to prevent reply storms of popular 1109 content requests. The client will also spread data block access 1110 among multiple serving clients that have the content (complete or 1111 partial) to improve latency and provide some load balancing. 1113 14.6. Discovery Mechanism 1115 The Distributed Cache mode uses multicast for discovery of other 1116 clients and content within a local network. Currently, the Hosted 1117 Cache mode uses policy provisioning or manual configuration of the 1118 server used as the Hosted Cache. 1120 14.7. Storage Mode 1122 Object-based. 1124 15. Conclusions 1126 Though there have been many successful in-network storage systems, 1127 they have been designed for use cases different from those defined in 1128 DECADE. As a result, their functionality and feature set does not 1129 meet the requirements defined for DECADE. DECADE aims to provide a 1130 standard protocol for P2P applications and content providers to 1131 access and control in-network storage, resulting in increased network 1132 efficiency while retaining control over content shared with peers. 1133 Additionally, defining a standard protocol can reduce complexity of 1134 in-network storage since multiple P2P application protocols no longer 1135 need to be implemented by in-network storage systems. 1137 16. Security Considerations 1139 This draft is a survey of existing in-network storage systems, and 1140 does not introduce any security considerations beyond those of the 1141 surveyed systems. 1143 For more information on security considerations of DECADE, see 1144 [I-D.song-decade-problem-statement]. 1146 17. IANA Considerations 1148 This document does not have any IANA Considerations. 1150 18. Acknowledgments 1152 The authors would like to thank Haibin Song, Yu-Shun Wang and Ning 1153 Zong for comments and contributions to this document. 1155 19. References 1156 19.1. Normative References 1158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1159 Requirement Levels", BCP 14, RFC 2119, March 1997. 1161 19.2. Informative References 1163 [I-D.song-decade-problem-statement] 1164 Yongchao, S., Zong, N., Yang, Y., and R. Alimi, "DECoupled 1165 Application Data Enroute (DECADE) Problem Statement", 1166 draft-song-decade-problem-statement-02 (work in progress), 1167 July 2010. 1169 [I-D.gu-decade-reqs] 1170 Yingjie, G., Yongchao, S., Yang, Y., and R. Alimi, "DECADE 1171 Requirements", draft-gu-decade-reqs-04 (work in progress), 1172 March 2010. 1174 [I-D.hammer-oauth] 1175 Hammer-Lahav, E., "The OAuth 1.0 Protocol", 1176 draft-hammer-oauth-10 (work in progress), February 2010. 1178 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1179 Protocol (CHAP)", RFC 1994, August 1996. 1181 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., 1182 and E. Zeidner, "Internet Small Computer Systems Interface 1183 (iSCSI)", RFC 3720, April 2004. 1185 [RFC4171] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and 1186 J. Souza, "Internet Storage Name Service (iSNS)", 1187 RFC 4171, September 2005. 1189 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 1190 System (NFS) Version 4 Minor Version 1 Protocol", 1191 RFC 5661, January 2010. 1193 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 1194 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 1196 [RFC5323] Reschke, J., Reddy, S., Davis, J., and A. Babich, "Web 1197 Distributed Authoring and Versioning (WebDAV) SEARCH", 1198 RFC 5323, November 2008. 1200 [RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties fo 1201 r Distributed Authoring and Versioning (DAV) Collections", 1202 RFC 4331, February 2006. 1204 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1205 Distributed Authoring and Versioning (WebDAV) 1206 Access Control Protocol", RFC 3744, May 2004. 1208 [I-D.ito-dav-ticket] 1209 Ito, K., "Ticket-Based Access Control Extension to 1210 WebDAV", draft-ito-dav-ticket-00 (work in progress), 1211 October 2001. 1213 [HYAL08] H. Xie, Y. R. Yang, A. Krishnamurthy, Y. Liu, and A. 1214 Silberschatz., "P4P: Provider Portal for Applications", In 1215 ACM SIGCOMM 2008. 1217 [MCM08] M. Hefeeda, C. Hsu, and K. Mokhtarian., "pCache: A Proxy 1218 Cache for Peer-to-Peer Traffic", In ACM SIGCOMM'08 1219 Technical Demonstration. 1221 [JZL08] Jie Wu, ZhiHui Lu, BiSheng Liu, et al., "PeerCDN: A Novel 1222 P2P Network Assisted Streaming Content Delivery Network 1223 Scheme", In 8th IEEE International Conference on Computer 1224 and Information Technology (CIT2008). 1226 [GYZ07] G. Shen, Y. Wang, Y. Xiong, B.Y. Zhao, Z.-L. Zhang, "HPTP: 1227 Relieving the tension between isps and p2p", In 6th 1228 International workshop on Peer-To-Peer Systems 1229 (IPTPS2007). 1231 [JCL09] Jiajun Wang, Cheng Huang, Jin Li., "On ISP-friendly rate 1232 allocation for peer-assisted VoD", In ACM Multimedia 2008. 1234 [GH09] Geoff Huston, Telstra., "Web Caching", In The Internet 1235 Protocol Journal Volume 2, No. 3. 1237 [McGraw02] 1238 Scott Hull et al., "Content Delivery Networks: Web 1239 Switching for Security, Availability, and Speed". 1241 [PR07] Pathan, A.K., Buyya, R., "A Taxonomy and Survey of Content 1242 Delivery Networks", In Grid Computing and Distributed 1243 Systems Laboratory in University of Melbourne, Technology 1244 Report, Feb. 2007. 1246 [AmazonS3] 1247 Amazon, "Amazon Simple Storage Service (Amazon S3)", 1248 http://aws.amazon.com/s3/. 1250 [Azure] Microsoft Corporation., "Windows Azure Blob - Programming 1251 Blob Storage". 1253 [OceanStore] 1254 S. Rhea, P. Eaton, D. Geels, H. Weatherspoon, B. Zhao, and 1255 J. Kubiatowicz., "Pond: the OceanStore Prototype", In FAST 1256 2003. 1258 [AVA09] A. Anand, V. Sekar, A. Akella., "SmartRE: An Architecture 1259 for Coordinated Network-wide Redundancy Elimination", In 1260 SIGCOMM 2009. 1262 [PRDW08] S. Paul, R. Yates, D. Raychaudhuri, J. Kurose., "The 1263 Cache-and-Forward Network Architecture for Efficient 1264 Mobile Content Delivery Services in the Future Internet", 1265 In Innovations in NGN: Future Network and Services, 2008. 1267 [BranchCache] 1268 Microsoft Corporation., "BranchCache", 1269 http://technet.microsoft.com/en-us/network/dd425028.aspx. 1271 Authors' Addresses 1273 Richard Alimi 1274 Yale University 1276 Email: richard.alimi@yale.edu 1278 ZhiHui Lu 1279 Fudan University 1281 Email: lzh@fudan.edu.cn 1283 Pang Tao 1284 China Telecom 1286 Email: pangt@gsta.com 1288 Yang Richard Yang 1289 Yale University 1291 Email: yry@cs.yale.edu