idnits 2.17.1 draft-ietf-decade-survey-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 date (August 31, 2011) is 4593 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-decade-problem-statement-03 == Outdated reference: A later version (-08) exists of draft-ietf-decade-reqs-03 -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '29') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3720 (ref. '30') (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 5661 (ref. '33') (Obsoleted by RFC 8881) -- Obsolete informational reference (is this intentional?): RFC 5849 (ref. '36') (Obsoleted by RFC 6749) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DECADE R. Alimi, Ed. 3 Internet-Draft Google 4 Intended status: Informational A. Rahman, Ed. 5 Expires: March 3, 2012 InterDigital Communications, LLC 6 Y. Yang, Ed. 7 Yale University 8 August 31, 2011 10 A Survey of In-network Storage Systems 11 draft-ietf-decade-survey-06 13 Abstract 15 This document surveys deployed and experimental in-network storage 16 systems and describes their applicability for the DECADE (DECoupled 17 Application Data Enroute) architecture. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 3, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Survey Overview . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Terminology and Concepts . . . . . . . . . . . . . . . . . 3 56 2.2. Historical Context . . . . . . . . . . . . . . . . . . . . 3 57 3. In-network Storage System Components . . . . . . . . . . . . . 5 58 3.1. Data Access Interface . . . . . . . . . . . . . . . . . . 5 59 3.2. Data Management Operations . . . . . . . . . . . . . . . . 5 60 3.3. Data Search Capability . . . . . . . . . . . . . . . . . . 5 61 3.4. Access Control Authorization . . . . . . . . . . . . . . . 6 62 3.5. Resource Control Interface . . . . . . . . . . . . . . . . 6 63 3.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 6 64 3.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 7 65 4. In-Network Storage Systems . . . . . . . . . . . . . . . . . . 7 66 4.1. Amazon S3 . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.2. BranchCache . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.3. Cache-and-Forward Architecture . . . . . . . . . . . . . . 11 69 4.4. Cloud Data Management Interface . . . . . . . . . . . . . 12 70 4.5. Content Delivery Network . . . . . . . . . . . . . . . . . 14 71 4.6. Delay-Tolerant Network . . . . . . . . . . . . . . . . . . 16 72 4.7. Named Data Networking . . . . . . . . . . . . . . . . . . 17 73 4.8. Network of Information . . . . . . . . . . . . . . . . . . 19 74 4.9. Network Traffic Redundancy Elimination . . . . . . . . . . 21 75 4.10. OceanStore . . . . . . . . . . . . . . . . . . . . . . . . 22 76 4.11. Photo Sharing . . . . . . . . . . . . . . . . . . . . . . 23 77 4.12. P2P Cache . . . . . . . . . . . . . . . . . . . . . . . . 25 78 4.13. Usenet . . . . . . . . . . . . . . . . . . . . . . . . . . 27 79 4.14. Web Cache . . . . . . . . . . . . . . . . . . . . . . . . 29 80 4.15. Observations Regarding In-Network Storage Systems . . . . 30 81 5. Storage And Other Related Protocols . . . . . . . . . . . . . 31 82 5.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 83 5.2. iSCSI . . . . . . . . . . . . . . . . . . . . . . . . . . 32 84 5.3. NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 85 5.4. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 35 86 5.5. WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . 36 87 5.6. Observations Regarding Storage and Related Protocols . . . 38 88 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 39 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 93 11. Informative References . . . . . . . . . . . . . . . . . . . . 40 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 96 1. Introduction 98 DECADE (DECoupled Application Data Enroute) is an architecture that 99 provides applications with access to provider based in-network 100 storage for content distribution (hereafter referred to as only "in- 101 network storage" in this document). With access to in-network 102 storage, content distribution applications can be designed to place 103 less load on network infrastructure. As a simple example, a peer of 104 a P2P application may upload to other peers through its in-network 105 storage, saving its usage of last-mile uplink bandwidth. See [1] for 106 further discussion. 108 A major motivation for DECADE is the substantial increase of capacity 109 and reduction in cost offered by storage systems. For example, over 110 the last two decades, there has been at least a 30-fold increase in 111 the amount of storage that you can get for a given price (for flash 112 memory and hard disk drives) [2], [3]. 114 High-capacity and low-cost in-network storage devices introduce 115 substantial opportunities. One example of in-network storage is 116 content caches supporting Web and Peer-to-Peer (P2P) content. 117 Different from existing content caches whose control fully reside at 118 the owners of the caching devices, DECADE also allows applications to 119 control access to their allocated in-network storage, as well as the 120 resources consumed while accessing that storage (bandwidth, 121 connections, storage space). While designed in the context of P2P 122 applications, it may be useful to other applications as well. This 123 document provides details on deployed and experimental in-network 124 storage solutions, and evaluates their suitability for DECADE. 126 We note that the survey presented in this document is only 127 representative of the research in this area. Rather than trying to 128 enumerate an exhaustive list, we have chosen some typical techniques 129 that lead to derivative works. 131 2. Survey Overview 133 2.1. Terminology and Concepts 135 This document uses terms defined in [1]. 137 2.2. Historical Context 139 In-network storage has been used previously in numerous scenarios to 140 reduce network traffic and enable more efficient content 141 distribution. This section presents a brief history of content 142 distribution techniques and illustrates how DECADE relates to past 143 approaches. Systems have been developed with particular use cases in 144 mind. Thus, this survey is not meant to point out shortcomings of 145 existing solutions, but rather to indicate where certain capabilities 146 required in DECADE [4] are not provided by existing systems. 148 In the early stage of Internet development, most Web content was 149 stored at a central server and clients requested Web content from the 150 central server. In this architecture, the central server was 151 required to provide a large amount of bandwidth. Web browsing is 152 still a primary activity on today's Internet. As more and more users 153 access Web content, a central server can become overloaded. The use 154 of web caches is one technique to reduce load on a central server. 155 Web caches store frequently-requested content, and provide bandwidth 156 for serving the content to clients. 158 The ongoing growth of broadband technology in the worldwide market 159 has been driven by the hunger of customers for new multimedia 160 services as well as Web content. In particular, the use of audio and 161 video streaming formats has become common for delivery of rich 162 information to the public, both residential and business. 164 To overcome this challenge of massive multimedia consumption, just 165 installing more Web cache will not be enough. Moving content closer 166 to the consumer results in greater network efficiency, improved QoS, 167 and lower latency, while facilitating personalization of content 168 through broadband content applications. In these edge technologies, 169 Content Delivery Networks (CDNs) is a representative technique. CDNs 170 are based on a large-scale distributed network of servers located 171 closer to the edges of the Internet for efficient delivery of digital 172 content including various forms of multimedia content. 174 Although CDN is an effective means of information access and 175 delivery, there are two barriers to making CDN a more common service: 176 cost and replication integrity. Deploying a CDN with its associated 177 infrastructure is expensive. A CDN also requires administrative 178 control over nodes with large storage capacity at geographically 179 dispersed locations with adequate connectivity. CDN can be scalable, 180 but due to this administrative and cost overhead, not rapidly 181 deployable for the common user. 183 The emergence and maturation of P2P has allowed improvements to many 184 network applications. P2P allows the use of client resources, such 185 as CPU, memory, storage, and bandwidth, for serving content. This 186 can reduce the amount of resources required by a content provider. 187 Multimedia content delivery using various P2P or peer-assisted 188 frameworks has been shown to greatly reduce the dependence on CDN and 189 central content servers. However, the popularity of P2P applications 190 has resulted in increased traffic on ISP networks. P2P caches (both 191 transparent and non-transparent) have been introduced as a way to 192 reduce the burden. Though they can be effective in reducing traffic 193 in certain areas of ISP networks, P2P caches have their shortcomings. 194 In particular, they are application-dependent and thus difficult to 195 keep up-to-date with new and evolving P2P application protocols. 196 Second, applications may benefit from explicit control of in-network 197 storage, which P2P caches do not provide. See [1] for further 198 discussion. 200 DECADE aims to provide a standard protocol allowing P2P applications 201 (including Content Providers) to make use of in-network storage to 202 reduce the traffic burden on ISP networks, while enabling P2P 203 applications to control access to content they have placed in in- 204 network storage. 206 3. In-network Storage System Components 208 Before surveying individual technologies, we describe the basic 209 components of in-network storage. For consistency and for ease of 210 comparison, we use the same model to evaluate each storage technology 211 in this document. 213 Note that the network protocol(s) used by a given storage system are 214 also an important part of the design. We omit details of particular 215 protocol choices in this document. 217 3.1. Data Access Interface 219 A set of operations available to a client user for accessing data in 220 the in-network storage. Solutions typically allow both read and 221 write, though the mechanisms for doing so can differ drastically. 223 3.2. Data Management Operations 225 Storage systems may provide users the ability to manage stored 226 content. For example, operations such as delete and move may be 227 provided to users. In this survey, we focus on data management 228 operations that are provided to client users and omit those provided 229 to system administrators. 231 3.3. Data Search Capability 233 Some storage systems may provide the capability to search or 234 enumerate content that has been stored. In this survey, we focus on 235 search capabilities that are provided to client users and omit those 236 provided to system administrators. An example of a client search 237 would be to find out the list of items stored by the given user over 238 a given period of time. 240 3.4. Access Control Authorization 242 Storage systems typically allow a client user, content owner or some 243 other entity to define the access policies for the in-network 244 storage. The in-network storage system then checks the authorization 245 of a user before it stores or retrieves content. We define three 246 types of access control authorization: public-unrestricted, public- 247 restricted, and private. 249 Public-unrestricted refers to content on an in-network storage system 250 that is widely available to all clients (i.e., without restrictions). 251 An example is accessing Wikipedia on the Web, or anonymous access to 252 FTP sites. 254 Public-restricted refers to content on an in-network storage system 255 that is available to a restricted (though still potentially large) 256 set of clients, but which do not require any confidential credentials 257 from the client. An example is some content (e.g., a TV show 258 episode) on the Internet that can only be viewable in selected 259 countries or networks (i.e., white/black lists or black-out areas). 261 Private refers to content on an in-network storage system that is 262 only made available to one or more clients presenting the required 263 confidential credentials (e.g., password or key). This content is 264 not available to anyone without the proper confidential access 265 credentials. 267 Note that a combination of access control types may be applicable for 268 a given scenario. For example, the retrieval (read) of content from 269 an in-network storage system may be public-unrestricted, but the 270 storage (write) to the same system may be private. 272 3.5. Resource Control Interface 274 This is the interface through which users manage the resources on in- 275 network storage that can be used by other peers, e.g., the bandwidth 276 or connections. The storage system may also allow users to indicate 277 a time for which resources are granted. 279 3.6. Discovery Mechanism 281 Users use the discovery mechanism to find location of in-network 282 storage, find access interface or resource control interface or other 283 interfaces of in-network storage. 285 3.7. Storage Mode 287 Storage systems may use the following modes of storage: file system, 288 object-based, or block-based. 290 A file system typically organizes files into a hierarchical tree 291 structure. Each level of the hierarchy normally contains one or more 292 directories each with one or more files. A file system may also be 293 flat or use some other organizing principle. 295 We define an object-based storage mode as one which stores discrete 296 chunks of data (e.g., IP datagrams or another type of aggregation 297 useful to an application) without a pre-defined hierarchy or meta 298 structure. 300 We define a block-based storage mode as one which stores a raw 301 sequence of bytes, with a client being able to read and/or write data 302 at offsets within that sequence. Data is typically accessed in 303 blocks for efficiency. An common example for this storage mode is 304 raw access to a hard disk. 306 In this survey, we define Storage Mode to refer to how data is 307 structured within the system, which may not be the same as how it is 308 accessed by a client. For example, a caching system may cache 309 objects with hierarchical names, but may internally use an object- 310 based Storage Mode. 312 4. In-Network Storage Systems 314 This section surveys in-network storage systems using the methodology 315 defined above. The survey includes some systems that are widely 316 deployed today, some systems that are just being deployed, and some 317 experimental/futuristic systems. The survey covers both traditional 318 client-server architectures and P2P architectures. The surveyed 319 systems are listed in alphabetical order. Also, for each system, a 320 brief explanation is given of the relevance to DECADE. 322 4.1. Amazon S3 324 Amazon S3 (Simple Storage Service) [5] provides an online storage 325 service using web (HTTP) interfaces. Users create buckets, and each 326 bucket can contain stored objects. Users are provided an interface 327 through which they can manage their buckets. Amazon S3 is a popular 328 backend storage for other services. Other related storage services 329 is the Blob Service provided by Windows Azure [6], Google Storage for 330 Developers [7], and Dropbox [8]. 332 4.1.1. Applicability to DECADE 334 Very widely used (deployed) example of in-network storage. Amazon 335 leases the storage to third party companies for disparate services. 336 In particular, Amazon S3 has a rich model for authorization (using 337 signed queries) to integrate with a wide variety of use cases. A 338 focus for Amazon S3 is scalability. Particular simplifications that 339 were made are the absence of a general, hierarchical namespace and 340 the inability to update the contents of existing data. 342 4.1.2. Data Access Interface 344 Users can read, and write objects. 346 4.1.3. Data Management Operations 348 Users can delete previously-stored objects. 350 4.1.4. Data Search Capability 352 Users can list contents of buckets to find objects matching desired 353 criteria. 355 4.1.5. Access Control Authorization 357 All methods of access control are supported for clients: public- 358 unrestricted, public-restricted and private. 360 For example, access to stored objects can be restricted by owner, a 361 list of other Amazon Web Service users, all Amazon Web Service Users, 362 or open to all users (anonymous access). Another option is for the 363 owner to generate and sign a query (e.g., a query to read an object) 364 that can be used by any user until an owner-defined expiration time. 366 4.1.6. Resource Control Interface 368 Not provided. 370 4.1.7. Discovery Mechanism 372 Users are provided a well-known DNS name (either a default provided 373 by Amazon, or one customized by a particular user). Users accessing 374 S3 storage use DNS to discover an IP address where S3 requests can be 375 sent. 377 4.1.8. Storage Mode 379 Object-based, with the extension that objects can be organized into 380 user-defined buckets. 382 4.2. BranchCache 384 BranchCache [9] is a feature integrated into Windows (Windows 7 and 385 Windows Server 2008R2) that aims to optimize enterprise branch office 386 file access over the WAN links. The main goals are to reduce WAN 387 link utilization and improve application responsiveness by caching 388 and sharing content within a branch while still maintaining end-to- 389 end security. BranchCache allows files retrieved from the web 390 servers and file servers located in headquarters or datacenters to be 391 cached in remote branch offices, and shared among users in the same 392 branch accessing the same content. BranchCache operates 393 transparently by instrumenting the HTTP and SMB components of the 394 networking stack. It provides two modes of operation: Distributed 395 Cache and Hosted Cache. 397 In both modes, a client always contacts a BranchCache-enabled content 398 server first to get the content identifiers for local search. If the 399 content is cached locally, the client then retrieves the content 400 within the branch. Otherwise, the client will go back to the 401 original content server to request the content. The two modes differ 402 in how the content is shared. 404 In the Hosted Cache mode, a locally provisioned server acts as a 405 cache for files retrieved from the servers. After getting the 406 content identifiers, the client first consults the cache for the 407 desired file. If it is not present in the cache, the client 408 retrieves it from the content server and sends it to the cache for 409 storage. 411 In the Distributed Cache mode, a client first queries other clients 412 in the same network using the Web Services Discovery multicast 413 protocol. As in the Hosted Cache mode, the client retrieves the file 414 from the content server if it is not available locally. After 415 retrieving the file (either from another client or the content 416 server), the client stores the file locally. 418 The original content server always authorizes requests from clients. 419 Cached content is encrypted such that only clients can decrypt the 420 data using keys derived from metadata returned by the content server. 421 In addition to instrumenting the networking stack at clients, content 422 servers must also support BranchCache. 424 4.2.1. Applicability to DECADE 426 BranchCache is an example of an in-network storage system primarily 427 targeted at enterprise networks. It supports both a P2P like mode 428 (Distributed Cache) as well as a client-server mode (Hosted Cache). 429 Integration into the Microsoft OS will ensure wide distribution of 430 this in-network storage technology. 432 4.2.2. Data Access Interface 434 Clients transparently retrieve (read) data from a cache (other 435 clients or a Hosted Cache) since it operates by instrumenting the 436 networking stack. In Hosted Cache mode, clients write data to the 437 Hosted Cache once it is retrieved from the content server. 439 4.2.3. Data Management Operations 441 Not provided. 443 4.2.4. Data Search Capability 445 Not provided. 447 4.2.5. Access Control Authorization 449 Access control method for clients is private. For example, 450 transferred content is encrypted, and can only be decrypted by keys 451 derived from data received from the original content server. Though 452 data may be transferred to unauthorized clients, end-to-end security 453 is maintained by only allowing authorized clients to decrypt the 454 data. 456 4.2.6. Resource Control Interface 458 The storage capacity of caches on the clients and Hosted Caches are 459 configurable by system administrators. The Hosted Cache further 460 allows configuration of the maximum number of simultaneous client 461 accesses. In the Distributed Caching mode, exponential back-off and 462 throttling mechanisms are utilized to prevent reply storms of popular 463 content requests. The client will also spread data block access 464 among multiple serving clients that have the content (complete or 465 partial) to improve latency and provide some load balancing. 467 4.2.7. Discovery Mechanism 469 The Distributed Cache mode uses multicast for discovery of other 470 clients and content within a local network. Currently, the Hosted 471 Cache mode uses policy provisioning or manual configuration of the 472 server used as the Hosted Cache. In this mode, the address of the 473 server may be found via DNS. 475 4.2.8. Storage Mode 477 Object-based. 479 4.3. Cache-and-Forward Architecture 481 Cache-and-Forward (CNF) [10] is an architecture for content delivery 482 services for the future Internet. In this architecture, storage can 483 be exploited at nodes within the network, either directly at routers 484 or deployed nearby the routers. CNF is based on the concept of 485 store-and-forward routers with large storage, providing for 486 opportunistic delivery to occasionally disconnected mobile users and 487 for in-network caching of content. The proposed CNF protocol uses 488 reliable hop-by-hop transfer of large data files between CNF routers 489 in place of an end-to-end transport protocol like TCP. 491 4.3.1. Applicability to DECADE 493 An example of an experimental in-network storage system that would 494 require storage space on (or near) a large number of routers in the 495 Internet if it was deployed. As the name of the system implies, it 496 would provide short term caching and not long term network storage. 498 4.3.2. Data Access Interface 500 Users implicitly store content at Cache-and-forward routers by 501 requesting files. End hosts read content from in-network storage by 502 submitting queries for content. 504 4.3.3. Data Management Operations 506 Not provided. 508 4.3.4. Data Search Capability 510 Not provided. 512 4.3.5. Access Control Authorization 514 Access control method is public-restricted (to any client which is 515 part of the cache-and-forward network). 517 4.3.6. Resource Control Interface 519 Not provided. 521 4.3.7. Discovery Mechanism 523 A query including a location-independent content ID is sent to the 524 network and routed to a Cache-and-forward router, which handles 525 retrieval of the data and forwarding to the end host. 527 4.3.8. Storage Mode 529 Object-based (with objects representing individual files). The 530 architecture proposes to cache large files in storage within the 531 network, though objects could be made to represent smaller chunks of 532 larger files. 534 4.4. Cloud Data Management Interface 536 The Cloud Data Management Interface (CDMI) is a specification to 537 access and manage cloud storage. CDMI is specified by the Storage 538 Networking Industry Association (SNIA). 540 CDMI is a functional interface that applications can use to create, 541 retrieve, update and delete data elements from the cloud. As part of 542 this interface the client will be able to discover the capabilities 543 of the cloud storage offering and use this interface to manage 544 containers and the data that is placed in them. In addition, 545 metadata can be set on containers and their contained data elements 546 through this interface [11]. 548 CDMI follows a traditional client server model, and operates over an 549 HTTP interface using the Representational State Transfer (REST) 550 model. Similar to Amazon S3 buckets (see Section 4.1), users may 551 create containers into which data objects may be stored. Even though 552 data objects may be accessed via a user-defined name within a 553 container, it is also possible to access data objects by a storage- 554 defined Object ID which is provided in the response upon creation of 555 a Data Object. 557 4.4.1. Applicability to DECADE 559 CDMI is an important initiative to standardize storage interfaces for 560 cloud services which are rapidly becoming an important storage 561 service. In particular, it specifies a set of operations for 562 creating, reading, writing, and managing data objects at a remote 563 server (or set of servers) via the HTTP protocol. 565 4.4.2. Data Access Interface 567 Users can read and write data objects, and also update data in 568 existing data objects. CDMI data objects are sent on the wire 569 embeded as a field in a JavaScript Object Notation (JSON) object. 570 The protocol also defines interfaces in which the contents of data 571 objects can be written via simple HTTP GET/PUT operations. 573 4.4.3. Data Management Operations 575 Users can delete already-existing data objects. The create operation 576 also supports modes in which the created object is copied or moved 577 from an existing data object. 579 Data System Metadata also allows users to configure policies 580 regarding time-to-live after which a data object is automatically 581 deleted, as well as the redundancy with which a data object is 582 stored. 584 4.4.4. Data Search Capability 586 Users may list the contents of containers to locate data objects 587 matching any desired criteria. 589 4.4.5. Access Control Authorization 591 All methods of access control for clients are supported: public- 592 unrestricted, public-restricted and private. 594 In particular CDMI allows access to data objects to be protected by 595 ACLs which can allow or restrict access based on user, group, 596 administrative status, or whether a user is authenticated or 597 anonymous. 599 4.4.6. Resource Control Interface 601 CDMI supports attributes 'cdmi_max_latency' and 'cdmi_max_throughput' 602 (set at either the level of containers, or a specific data object) 603 which control the level of service offered to any users accessing a 604 particular data object. 606 4.4.7. Discovery Mechanism 608 Users are provided a well-known DNS name. The DNS name is resolved 609 to determine the IP address to which requests may be sent. 611 4.4.8. Storage Mode 613 Object-based, with the extension that objects can be organized into 614 user-defined containers. 616 4.5. Content Delivery Network 618 A CDN provides services that improve performance by minimizing the 619 amount of data transmitted through the network, improving 620 accessibility and maintaining correctness through content 621 replication. CDNs offer fast and reliable applications and services 622 by distributing content to cache or edge servers located close to 623 users. See [12] for an additional taxonomy and survey. 625 A CDN has some combination of content-delivery, request-routing, 626 distribution and accounting infrastructure. The content-delivery 627 infrastructure consists of a set of edge servers (also called 628 surrogates) that deliver copies of content to end-users. The 629 request-routing infrastructure is responsible for directing client 630 requests to appropriate edge servers. It also interacts with the 631 distribution infrastructure to keep an up-to-date view of the content 632 stored in the CDN caches. The distribution infrastructure moves 633 content from the origin server to the CDN edge servers and ensures 634 consistency of content in the caches. The accounting infrastructure 635 maintains logs of client accesses and records the usage of the CDN 636 servers. This information is used for traffic reporting and usage- 637 based billing. 639 In practice, a CDN typically hosts static content including images, 640 video, media clips, advertisements, and other embedded objects for 641 Web viewing. A focus for CDNs is the ability to publish and deliver 642 content to end-users in a reliable and timely manner. A CDN focuses 643 on building its network infrastructure to provide the following 644 services and functionalities: storage and management of content; 645 distribution of content among surrogates; cache management; delivery 646 of static, dynamic and streaming content; backup and disaster 647 recovery solutions; and monitoring, performance measurement and 648 reporting. 650 Examples of existing CDNs are Akamai, Limelight, and CloudFront. 652 The following description uses the term "content provider" to refer 653 to the entity purchasing a CDN service, and the term "client" to 654 refer to the subscriber requesting content via the CDN from the 655 content provider. 657 4.5.1. Applicability to DECADE 659 Very widely used (deployed) example of in-network storage for 660 multimedia content. The existence and operation of the storage is 661 totally transparent to the end user. A CDN typically require a 662 strong business relationship between the content providers and 663 content distributors and often the business relationship extends to 664 the ISPs. 666 4.5.2. Data Access Interface 668 A CDN is typically a closed system, and generally provides only read 669 (retrieve) access interface to clients. A CDN typically does not 670 provide write (store) access interface to clients. The content 671 provider can access network edge servers and store content on them, 672 or edge servers can retrieve content from content providers. Client 673 nodes can just retrieve content from edge servers. 675 4.5.3. Data Management Operations 677 A content provider can manage the data distributed in different cache 678 nodes, such as moving popular data objects from one cache node to 679 another cache node, or deleting rarely-accessed data objects in cache 680 nodes. Client user nodes, however, have no right to perform these 681 operations. 683 4.5.4. Data Search Capability 685 A content provider can search or enumerate the data each cache node 686 stores. Client user nodes cannot perform search operations. 688 4.5.5. Access Control Authorization 690 All methods of access control (for reading) are supported for 691 clients: public-unrestricted, public-restricted and private. Some 692 CDN edge servers will allow usage of HTTP basic authentication with 693 the origin server, restrictions by IP address, or they can use a 694 token-based technique to allow the origin server to apply its own 695 authorization criteria. 697 As mentioned previously, clients typically cannot write to the CDN. 698 Writing is typically a private operation for the content providers. 700 4.5.6. Resource Control Interface 702 Not provided. 704 4.5.7. Discovery Mechanism 706 Content providers can directly find internal CDN cache nodes to store 707 content, since they typically have an explicit business relationship. 708 Clients can locate CDN nodes through DNS or other redirection 709 mechanisms. 711 4.5.8. Storage Mode 713 Though addressing objects uses URLs which typically refer to objects 714 in a hierarchical fashion, the storage mode is typically object- 715 based. 717 4.6. Delay-Tolerant Network 719 The Delay-Tolerant Network (DTN) [13] is an evolution of an 720 architecture originally designed for the Interplanetary Internet. 721 The Interplanetary Internet is a communication system envisioned to 722 provide Internet-like services across interplanetary distances in 723 support of deep space exploration. The DTN architecture can be 724 utilized in various operational environments characterized by severe 725 communication disruptions, disconnections and high-delays (e.g., a 726 month long loss of connectivity between two planetary networks 727 because of high solar radiation due to sun spots). The DTN 728 architecture is thus suitable for environments including deep space 729 networks, sensor-based networks, certain satellite networks and 730 underwater acoustic networks. 732 A key aspect of the DTN is a store and forward overlay layer called 733 the "Bundle Protocol" or "Bundle Layer" that exists between the 734 transport and application layers [14]. The Bundle Layer forms a 735 logical overlay that employs persistent storage to help combat long 736 term network interruptions by providing a store and forwarding 737 service. While traditional IP networks are also based on store and 738 forward principles, the amount of time of a packet being kept in 739 "storage" at a traditional IP router is typically in the order of 740 milli-seconds (or less). In contrast, the DTN architecture assumes 741 that most Bundle Layer nodes will use some form of persistent storage 742 (e.g., hard disk, flash memory, etc.) for DTN packets because of the 743 nature of the DTN environment. 745 4.6.1. Applicability to DECADE 747 An example of an experimental in-network storage system that would 748 require fundamental changes to the Internet protocols. 750 4.6.2. Data Access Interface 752 Users implicitly cause content to be stored (until successfully 753 forwarded) at Bundle Layer nodes by initiating/terminating any 754 transaction that traverses the DTN. 756 4.6.3. Data Management Operations 758 Users can implicitly cause deletion of content stored at Bundle Layer 759 nodes via a "Time To Live" type parameter that the user can control 760 (for transactions originating from the user). 762 4.6.4. Data Search Capability 764 Not provided. 766 4.6.5. Access Control Authorization 768 Access control method is public-restricted (to any client which is 769 part of the DTN) or private. 771 4.6.6. Resource Control Interface 773 Not provided. 775 4.6.7. Discovery Mechanism 777 A Uniform Resource Identifier (URI) approach is used as the basis of 778 the addressing scheme for DTN transactions (and subsequent store and 779 forward routing through the DTN network). 781 4.6.8. Storage Mode 783 Object-based. DTN applications send data to the Bundle Layer which 784 then breaks the data into segments. These segments are then routed 785 through the DTN network, and stored in Bundle Layer nodes as required 786 (before being forwarded). 788 4.7. Named Data Networking 790 Named Data Networking (NDN) [15] is a research initiative which 791 proposes to move to a new model of addressing and routing for the 792 Internet. NDN uses "named data" based routing and forwarding, to 793 replace the current IP address based model. NDN also uses name-based 794 data caching in the routers. 796 Each NDN Data packet will be assigned a content name and will be 797 cryptographically signed. Data delivery is driven by the requesting 798 end. Routers disseminate name-based prefix announcements by using 799 routing protocols like Intermediate System to Intermediate System 800 (IS-IS) or Border Gateway Protocol (BGP). The requester will send 801 out an "Interest" packet which identifies the name of the data that 802 it wants. Routers that receive this Interest packet will remember 803 the interface it came from and will then forward it on a named-based 804 routing protocol. Once an Interest packet reaches a node that has 805 the desired data, a named Data packet is sent back, which carries 806 both the name and content of the data, along with a digital signature 807 of the producer. This named Data packet is then forwarded back to 808 the original requester on the reverse path of the Interest packet 809 [16]. 811 A key aspect of NDN is that routers have the capability to cache the 812 named data. If a request for the same data (i.e., same name) comes 813 to the router, then the NDN router will forward the named data stored 814 locally to fulfill the request. The proponents of NDN believe that 815 the network can be designed naturally matching data delivery 816 characteristics instead of communication between endpoints because 817 data delivery has become the primary use of the network. 819 4.7.1. Applicability to DECADE 821 An example of an experimental in-network storage system that would 822 require storage space on a large number of routers in the Internet. 823 Named Data packets would be kept in storage in the NDN routers and 824 provided to new requesters of the same data. 826 4.7.2. Data Access Interface 828 Users implicitly store content at NDN routers by requesting content 829 (named Data packets) from the network. Subsequent requests by 830 different users for the same content will cause the named Data 831 packets to be read from the NDN routers in-network storage. 833 4.7.3. Data Management Operations 835 Users do not have the direct ability to delete content stored in the 836 NDN routers. However, there will be some type of "Time To Live" 837 parameter associated with the named Data packets though this has not 838 yet been specified. 840 4.7.4. Data Search Capability 842 Not provided. 844 4.7.5. Access Control Authorization 846 All methods of access control for clients are supported: public- 847 unrestricted, public-restricted and private. 849 The basic security mechanism in NDN is for the sender to digitally 850 sign the content (named Data packet) that it sends. It is envisioned 851 that a complete access control system can be built on top of this 852 though this has not yet been specified. 854 4.7.6. Resource Control Interface 856 Not provided. 858 4.7.7. Discovery Mechanism 860 Names are used as the basis of the addressing and discovery scheme 861 for NDN (and subsequent store and forward routing through the NDN 862 network). NDN names are assumed to be hierarchical and to be able to 863 be deterministically constructed. This is still an active area of 864 research. 866 4.7.8. Storage Mode 868 Object-based. NDN sends named Data packets through the network. 869 These Data packets are routed through the NDN network, and stored in 870 NDN routers. 872 4.8. Network of Information 874 Similar to NDN (see Section 4.7), Network of Information (NetInf) 875 [17] is another information centric approach in which the named data 876 objects are the basic component of the networking architecture. 877 NetInf is thus moving away from today's host centric networking 878 architecture where the nodes in the network are the primary objects. 879 In today's network the information objects are named relative to the 880 hosts they are stored on (e.g., 881 http://www.example.com/information-object.txt). 883 The NetInf naming and security framework builds the foundation for an 884 information centric security model that integrates security deeply 885 into the architecture. In this model, trust is based on the 886 information itself. Information Objects (IOs) are given a unique 887 name with cryptographic properties. Together with additional 888 metadata, the name can be used to verify the data integrity as well 889 as several other security properties, like self-certification, name 890 persistency, and owner authentication and identification. The 891 approach also gives some benefits over the security model in today's 892 host centric networks, as it minimizes the need for trust in the 893 infrastructure, including the hosts providing the data, the channel, 894 or the resolution service. 896 In NetInf the information objects are published into the network. 897 They are registered with a Name Resolution Service (NRS). The NRS is 898 also used to register network locators that can be used to retrieve 899 data objects that represent the published IOs. When a receiver wants 900 to retrieve an IO, the request for the IO is resolved by the NRS into 901 a set of locators. These locators are then used to retrieve a copy 902 of the data object from the "best" available source(s). NetInf is 903 open to use any type of underlying transport networks. The locators 904 can thus be a heterogeneous set, e.g., IPv4, IPv6, MAC, etc. 906 NetInf will make extensive use of caching of information objects in 907 the network and will provide network functionality that is similar to 908 what overlay solutions like CDNs and P2P distribution networks (e.g., 909 BitTorrent) provide today. 911 4.8.1. Applicability to DECADE 913 An example of an experimental information centric network 914 architecture that will require storage space for storage and caching 915 of information objects on a large number of NetInf nodes in the 916 Internet. 918 4.8.2. Data Access Interface 920 Users will publish IOs with specific IDs into the network. This is 921 done by the client sending a register message to the NRS stating that 922 the IO with the specific ID is available. When another user wishes 923 to retrieve the IO they will use the given ID to make a request for 924 the IO. The ID is then resolved by the NRS and the IO is delivered 925 from a nearby in-network storage location. 927 4.8.3. Data Management Operations 929 Users do not have the direct ability to delete content stored in the 930 NetInf nodes. However, there can be some type of "Time To Live" 931 parameter associated with the information objects though this has not 932 yet been specified. 934 4.8.4. Data Search Capability 936 Not provided. 938 4.8.5. Access Control Authorization 940 All methods of access control for clients are supported: public- 941 unrestricted, public-restricted and private. The basic security 942 mechanism in NetInf is for the publisher to digitally sign the 943 content of the information object that it publish. It is envisioned 944 that a complete access control system can be built on top of this 945 though this has not yet been specified. 947 4.8.6. Resource Control Interface 949 Not provided. 951 4.8.7. Discovery Mechanism 953 NetInf IDs are used for naming and accessing information objects. 954 The IDs are resolved by the NRS into locators that are used for 955 routing and transport of data through the transport networks. This 956 is still an active area of research. 958 4.8.8. Storage Mode 960 Object-based. From an application perspective NetInf can be used for 961 publishing entire files or chunks of files. NetInf is agnostic to 962 the application perspective and treats everything as information 963 objects. 965 4.9. Network Traffic Redundancy Elimination 967 Redundancy Elimination (RE) (e.g., [18]) is used for identifying and 968 removing repeated content from network transfers. This technique has 969 been proposed to improve network performance in many types of 970 networks, such as ISP backbones and enterprise access links. One 971 example of redundancy elimination proposal is SmartRE, proposed by 972 Anand et al., which focuses on network-wide redundancy elimination. 973 In packet-level redundancy elimination, forwarding elements are 974 equipped with additional storage which can be used to cache data from 975 forwarded packets. Upstream routers may replace packet data with a 976 fingerprint that tells a downstream router how to decode and 977 reconstruct the packet based on cached data. 979 4.9.1. Applicability to DECADE 981 An example of an experimental in-network storage system that would 982 require a large amount of associated packet processing at routers if 983 it was ever deployed. 985 4.9.2. Data Access Interface 987 Redundancy-elimination are typically transparent to the user. 988 Writing into the storage is done by transferring data that has not 989 already been cached. Storage is read when users transmit data 990 identical to previously-transmitted data. 992 4.9.3. Data Management Operations 994 Not provided. 996 4.9.4. Data Search Capability 998 Not provided. 1000 4.9.5. Access Control Authorization 1002 Access control method is public-restricted (to any client which is 1003 part of the RE network). Note that the content provider still 1004 retains control over which peers receive the requested data. The 1005 returned data is "compressed" as it is transferred within the 1006 network. 1008 4.9.6. Resource Control Interface 1010 Not provided. The content provider still retains control over the 1011 rate at which packets are sent to a peer. The packet size within the 1012 network may be reduced. 1014 4.9.7. Discovery Mechanism 1016 No discovery mechanism is necessary. Routers can use redundancy- 1017 elimination without the users' knowledge. 1019 4.9.8. Storage Mode 1021 Object-based, with "objects" being data from packets transmitted 1022 within the network. 1024 4.10. OceanStore 1026 OceanStore [19] is a storage platform developed at University of 1027 California, Berkeley, that provides globally-distributed storage. 1028 OceanStore implements a model where multiple storage providers can 1029 pool resources together. Thus, a major focus is on resiliency and 1030 self-organization and self-maintenance. 1032 The protocol is resilient to some storage nodes being compromised by 1033 utilizing Byzantine agreement and erasure codes to store data at 1034 primary replicas. 1036 4.10.1. Applicability to DECADE 1038 An example of an experimental in-network storage system that provides 1039 a high degree of network resilience to failure scenarios. 1041 4.10.2. Data Access Interface 1043 Users may read and write objects 1045 4.10.3. Data Management Operations 1047 Objects may be replaced by newer versions, and multiple versions of 1048 an object may be maintained. 1050 4.10.4. Data Search Capability 1052 Not provided. 1054 4.10.5. Access Control Authorization 1056 Provided, but specifics for clients are unclear from the available 1057 references. 1059 4.10.6. Resource Control Interface 1061 Not provided. 1063 4.10.7. Discovery Mechanism 1065 Users require an entry-point into the system in the form of one 1066 storage node that is part of OceanStore. If a hostname is provided, 1067 the address of a storage node may be determined via DNS. 1069 4.10.8. Storage Mode 1071 Object-based. 1073 4.11. Photo Sharing 1075 There are a growing number of popular on line Photo Sharing (storing) 1076 systems. For example, the Kodak Gallery system [20] serves over 60 1077 million users and stores billions of images [21]. Other well known 1078 examples of Photo Sharing systems include Flickr [22] and ImageShack 1079 [23]. Also there are a number of popular blogging services, such as 1080 Tumblr [24], which specialize in also sharing large numbers of photos 1081 and other multimedia content (e.g., video, text, audio, etc.) as part 1082 of their service. All these in-network storage systems utilize both 1083 free and paid subscription models. 1085 Most Photo Sharing systems are traditional client-server 1086 architecture. However, a minority of systems also offer a P2P mode 1087 of operation. The client-server architecture is typically based on 1088 HTTP with a browser client and a web server. 1090 4.11.1. Applicability to DECADE 1092 Very widely used (deployed) example of in-network storage where the 1093 end user has direct visibility and extensive control of the system. 1094 Typical end user interface is through a HTTP based web browser. 1096 4.11.2. Data Access Interface 1098 Users can read (view) and write (store) photos. 1100 4.11.3. Data Management Operations 1102 Users can delete previously stored photos. 1104 4.11.4. Data Search Capability 1106 Users can tag photos and/or organize them using sophisticated web 1107 photo album generators. Users can then search for objects (photos) 1108 matching desired criteria. 1110 4.11.5. Access Control Authorization 1112 Access control method for clients is typically either private or 1113 public-unrestricted. For example, writing (storing) to a Photo blog 1114 is typically private to the owner of the account. However, all other 1115 clients can view (read) the contents of the blog (i.e., public- 1116 unrestricted). Some photo sharing websites provide private access to 1117 read photos to allow sharing with a limited set of friends. 1119 4.11.6. Resource Control Interface 1121 Not provided. 1123 4.11.7. Discovery Mechanism 1125 Usually by manually logging on to a central web page for the service 1126 and entering the appropriate information to access the desired 1127 information. The address to which the client connects is usually 1128 determined by DNS using the hostname from the provided URL. 1130 4.11.8. Storage Mode 1132 File-based. Photos are usually stored as files. They can then be 1133 organized into meta-structures (e.g., albums, galleries, etc.) using 1134 sophisticated web photo album generators. 1136 4.12. P2P Cache 1138 Caching of P2P traffic is a useful approach to reduce P2P network 1139 traffic, because objects in P2P systems are mostly immutable and the 1140 traffic is highly repetitive. In addition, making use of P2P caches 1141 does not require changes to P2P protocols and can be deployed 1142 transparently from clients. 1144 P2P caches operate similarly to web caches (Section 4.14) in that 1145 they temporarily store frequently-requested content. Requests for 1146 content already stored in the cache can be served from local storage 1147 instead of requiring the data to be transmitted over expensive 1148 network links. 1150 Two types of P2P caches exist: non-transparent P2P caches and 1151 transparent P2P caches. A non-transparent cache appears as a super 1152 peer; it explicitly peers with other P2P clients. For a transparent 1153 cache, once a P2P cache is established, the network will 1154 transparently redirect P2P traffic to the cache, which either serves 1155 the file directly or passes the request on to a remote P2P user and 1156 simultaneously caches that data. Transparency is typically 1157 implemented using Deep Packet Inspection (DPI). DPI products 1158 identify and pass P2P packets to the P2P caching system so it can 1159 cache the traffic and accelerate it. 1161 To enable operation with existing P2P software, P2P caches directly 1162 support P2P application protocols. A large number of P2P protocols 1163 are used by P2P software, and hence are supported by caches, leading 1164 to higher complexity. Additionally, these protocols evolve over 1165 time, and new protocols are introduced. 1167 4.12.1. Applicability to DECADE 1169 An example of in-network storage for P2P systems. However, unlike 1170 DECADE, the existence and operation of the storage is totally 1171 transparent to the end user. 1173 4.12.2. Transparent P2P Caches 1174 4.12.2.1. Data Access Interface 1176 Data Access Interface allows P2P content to be cached (stored) and 1177 supplied (retrieved) locally such that network traffic is reduced, 1178 but it is transparent to P2P users, and P2P users implicitly use the 1179 data-access interface (in the form of their native P2P application 1180 protocol) to store or retrieve content. 1182 4.12.2.2. Data Management Operations 1184 Not provided. 1186 4.12.2.3. Data Search Capability 1188 Not provided. 1190 4.12.2.4. Access Control Authorization 1192 Access control method is typically public-restricted (to any client 1193 which is part of the P2P channel or swarm). 1195 4.12.2.5. Resource Control Interface 1197 Not provided. 1199 4.12.2.6. Discovery Mechanism 1201 Use of DPI means no discovery mechanism is provided to P2P users, it 1202 is transparent to P2P users. Since DPI is used to recognize P2P 1203 applications' private protocols, P2P Cache implementations must be 1204 updated as new applications are added and existing protocols evolve. 1206 4.12.2.7. Storage Mode 1208 Object-based. Chunks (typically, the unit of transfer amongst P2P 1209 clients) of content are stored in the cache. 1211 4.12.3. Non-transparent P2P Caches 1213 4.12.3.1. Data Access Interface 1215 Data Access Interface allows P2P content to be cached (stored) and 1216 supplied (retrieved) locally such that network traffic is reduced. 1217 P2P users implicitly store and retrieve from the cache using the P2P 1218 application's native protocol. 1220 4.12.3.2. Data Management Operations 1222 Not provided. 1224 4.12.3.3. Data Search Capability 1226 Not provided. 1228 4.12.3.4. Access Control Authorization 1230 Access control method is typically public-restricted (to any client 1231 which is part of the P2P channel or swarm) 1233 4.12.3.5. Resource Control Interface 1235 Not provided. 1237 4.12.3.6. Discovery Mechanism 1239 A cache pretends to be normal peers to join the P2P overlay network. 1240 Other P2P users can find these cache nodes through overlay routing 1241 mechanism, just looking to them as normal neighbor nodes. 1243 4.12.3.7. Storage Mode 1245 Object-based. Chunks (typically, the unit of transfer amongst P2P 1246 clients) of content are stored in the cache. 1248 4.13. Usenet 1250 Usenet is a distributed Internet based discussion (message) system. 1251 The Usenet messages are arranged as a set of "newsgroups" that are 1252 classified hierarchically by subject. Usenet information is 1253 distributed and stored among a large conglomeration of servers that 1254 store and forward messages to one another in so called news feeds. 1255 Individual users may read messages from and post messages to a local 1256 news server typically operated by an ISP. This local server 1257 communicates with other servers and exchanges articles with them. In 1258 this fashion, the message is copied from server to server and 1259 eventually reaches every server in the network [25]. 1261 Traditional Usenet as described above operates as a P2P network 1262 between the servers, and in a client-server architecture between the 1263 user and their local news server. The user requires a Usenet client 1264 to be installed on their computer and a Usenet server account 1265 (through their ISP). However, with the rise of web browsers the 1266 Usenet architecture is evolving to be web based. The most popular 1267 example of this is Google Groups where Google hosts all the 1268 newsgroups and client access is via a standard HTTP based web browser 1269 [26]. 1271 4.13.1. Applicability to DECADE 1273 A historically very important and widely used (deployed) example of 1274 in-network storage in the Internet. The use of this system is 1275 rapidly declining but efforts have been made to preserve the stored 1276 content for historical purposes. 1278 4.13.2. Data Access Interface 1280 Users can read and post (store) messages. 1282 4.13.3. Data Management Operations 1284 Users sometimes have limited ability to delete messages that they 1285 previously posted. 1287 4.13.4. Data Search Capability 1289 Traditionally, users could manually search through the newsgroups as 1290 they are classified hierarchically by subject. In the newer web 1291 based systems there is also automatic search capability based on key 1292 word matches. 1294 4.13.5. Access Control Authorization 1296 Access control method is either public-unrestricted or private (to 1297 client members of that newsgroup). 1299 4.13.6. Resource Control Interface 1301 Not provided. 1303 4.13.7. Discovery Mechanism 1305 Usually by manually logging on to the Usenet account. DNS may be 1306 used to resolve hostnames to their corresponding addresses. 1308 4.13.8. Storage Mode 1310 File system. Messages are usually stored as files which are then 1311 organized hierarchically by subject into newsgroups. 1313 4.14. Web Cache 1315 Web cache [27] has been widely deployed by many ISPs to reduce 1316 bandwidth consumption and web access latency since the late 1990s. A 1317 web cache can cache the web documents (e.g., HTML pages, images) 1318 between server and client to reduce bandwidth usage, server load, and 1319 perceived lag. A web cache server is typically shared by many 1320 clients, and stores copies of documents passing through it; 1321 subsequent requests may be satisfied from the cache if certain 1322 conditions are met. 1324 Another form of cache is a client-side cache, typically implemented 1325 in web browsers. A client side cache can keep a local copy of all 1326 pages recently displayed by browser, and when the user returns to one 1327 of these web pages, the local cached copy is reused. 1329 A related protocol for P2P applications to use web cache is HPTP 1330 (HTTP based Peer to Peer) [28]. It proposes to share chunks of P2P 1331 files/streams using HTTP protocol with cache-control headers. 1333 4.14.1. Applicability to DECADE 1335 Very widely used (deployed) example of in-network storage for the key 1336 Internet application of Web browsing. The existence and operation of 1337 the storage is transparent to the end user in most cases. The 1338 content caching time is controlled by Time To Live parameters 1339 associated with the original content. The principle of web caching 1340 is to speed up web page reading by using (the same) content 1341 previously requested by a preceding user to service a new user. 1343 4.14.2. Data Access Interface 1345 Users explicitly read from a web cache by making requests, but they 1346 cannot explicitly write data into it. Data is implicitly stored into 1347 the web cache by requesting content that is not already cached and 1348 meets policy restrictions of the cache provider. 1350 4.14.3. Data Management Operations 1352 Not provided. 1354 4.14.4. Data Search Capability 1356 Not provided. 1358 4.14.5. Access Control Authorization 1360 Access control method for clients is public-unrestricted. It is 1361 important to note that if content is authenticated or encrypted 1362 (e.g., HTTPS, SSL) it will not be cached. Also if the content is 1363 flagged as private (vs public) at the HTTP level by the origin server 1364 it will not be cached. 1366 4.14.6. Resource Control Interface 1368 Not provided. 1370 4.14.7. Discovery Mechanism 1372 Web Caches can be transparently deployed between Web Server and Web 1373 Clients, employing DPI for discovery. Alternatively, web caches 1374 could be explicitly discovered by clients using techniques such as 1375 DNS or manual configuration. 1377 4.14.8. Storage Mode 1379 Object based. Web content is keyed within the cache by HTTP Request 1380 fields, such as Method, URI, and Headers. 1382 4.15. Observations Regarding In-Network Storage Systems 1384 This following observations about the surveyed In-Network storage 1385 systems are made in the context of DECADE as defined by [1]. 1387 The majority of the surveyed systems were designed for client-server 1388 architectures and do not support P2P. However, there are some 1389 important exceptions, especially for some of the newer technologies 1390 such as BranchCache and P2P Cache which do support a P2P mode. 1392 The P2P cache systems are interesting since they do not require 1393 changes to P2P applications themselves. However, this is also a 1394 limitation in that they are required to support each application 1395 protocol. 1397 Many of the surveyed systems were designed for caching as opposed to 1398 long term network storage. Thus during DECADE protocol design it 1399 should be carefully considered if a caching mode should be supported 1400 in addition to a long term network storage mode. There is typically 1401 a trade-off between providing a caching mode and long-term (and 1402 usually also reliable) storage with regards to some performance 1403 metrics. Note that [1] identifies issues with classical caching from 1404 a DECADE perspective such as the fact that P2P caches typically do 1405 not allow users to explicitly control content stored in the cache. 1407 Certain components of the surveyed systems are outside of the scope 1408 of DECADE. For example, a protocol used for searching across 1409 multiple DECADE servers is out of scope. However, applications may 1410 still be able to implement such functionality if DECADE exposes the 1411 appropriate primitives. This has the benefit of keeping the core in- 1412 network storage systems simple, while permitting diverse applications 1413 to design mechanisms that meet their own requirements. 1415 Today, most in-network storage systems follow some variant of the 1416 authorization model of public-unrestricted, public-restricted, and 1417 private. For DECADE, we may need to evolve the authorization model 1418 to support a resource owner (e.g., end user) authorization, in 1419 addition to the network authorization. 1421 5. Storage And Other Related Protocols 1423 This section surveys existing storage and other related protocols, as 1424 well as comments on the usage of these protocols to satisfy DECADE's 1425 use cases. The surveyed protocols are listed alphabetically. 1427 5.1. HTTP 1429 HTTP [29] is a key protocol for the World Wide Web. It is a stateless 1430 client-server protocol that allows applications to be designed using 1431 the REST model. HTTP is often associated with downloading (reading) 1432 content from web servers to web browsers, but it also has support for 1433 uploading (writing) of content to web servers. It has been used as 1434 the underlying protocol for other protocols such as WebDAV. 1436 HTTP is used in some of the most popular in-network storage systems 1437 surveyed previously including CDNs, Photo Sharing, and Web Cache. 1438 Usage of HTTP by a storage protocol implies that no extra SW is 1439 required in the client (i.e., web based client) as all standard Web 1440 browsers are based on HTTP. 1442 5.1.1. Data Access Interface 1444 Basic read and write operations are supported (using HTTP GET, PUT 1445 and POST methods). 1447 5.1.2. Data Management Operations 1449 Not provided. 1451 5.1.3. Data Search Capability 1453 Not provided 1455 5.1.4. Access Control Authorization 1457 All methods of access control for clients are supported: public- 1458 unrestricted, public-restricted and private. 1460 The majority of web pages are public-unrestricted in terms of reading 1461 but do not allow any uploading of content. In-network storage 1462 systems range from private or public-unrestricted for Photo Sharing 1463 described in Section 4.11.5 to public-unrestricted for Web Caching 1464 described in Section 4.14.5. 1466 5.1.5. Resource Control Interface 1468 Not provided. 1470 5.1.6. Discovery Mechanism 1472 Manual configuration is typically used. Clients typically address 1473 HTTP servers by providing a hostname, which is resolved to an address 1474 using DNS. 1476 5.1.7. Storage Mode 1478 HTTP is a protocol, it thus does not define a Storage Mode. However, 1479 a non-collection resource can typically be thought of as a "file"). 1480 These files may be organized into collections, which typically map on 1481 to the HTTP Path hierarchy, creating the illusion of a file system. 1483 5.1.8. Comments 1485 HTTP is based on a client-server architecture and thus is not 1486 directly applicable for the DECADE focus on P2P. Also, HTTP offers 1487 only a rudimentary toolset for storage operations compared to some of 1488 the other storage protocols. 1490 5.2. iSCSI 1492 Small Computer System Interface (SCSI) is a set of protocols enabling 1493 communication with storage devices such as disk drives and tapes; 1494 internet SCSI (iSCSI) [30] is a protocol enabling SCSI commands to be 1495 sent over TCP. As in SCSI, iSCSI allows an Initiator to send 1496 commands to a Target. These commands operate on the device level as 1497 opposed to individual data objects stored on the device. 1499 5.2.1. Data Access Interface 1501 Read and write commands indicate which data is to be read or written 1502 by specifying the offset (using Logical Block Addressing) into the 1503 storage device. The size of data to be read or written is an 1504 additional parameter in the command. 1506 5.2.2. Data Management Operations 1508 Since commands operate at the device level, management operations are 1509 different than with traditional file systems. Management commands 1510 for SCSI/iSCSI including explicit device control such as starting and 1511 stopping the device and formatting the device. 1513 5.2.3. Data Search Capability 1515 SCSI/iSCSI does not provide the ability to search for particular data 1516 within a device. Note that such capabilities can be implemented 1517 outside of iSCSI. 1519 5.2.4. Access Control Authorization 1521 With respect to access to devices, the access control method is 1522 private. iSCSI uses CHAP [31] to authenticate initiators and targets 1523 when accessing storage devices. However, since SCSI/iSCSI operates 1524 at the device level, neither authentication nor authorization are 1525 provided for individual data objects. Note that such capabilities 1526 can be implemented outside of iSCSI. 1528 5.2.5. Resource Control Interface 1530 Not provided. 1532 5.2.6. Discovery Mechanism 1534 Manual configuration may be used. An alternative is the internet 1535 Storage Name Service (iSNS) [32] provides the ability to discover 1536 available storage resources. 1538 5.2.7. Storage Mode 1540 As a protocol, iSCSI does not explicitly have a storage mode. 1541 However, it provides block-based access to clients. SCSI/iSCSI 1542 provides an Initiator block-level access to the storage device. 1544 5.3. NFS 1546 The Network File System is designed to allow users to access files 1547 over a network in a manner similar to how local storage is accessed. 1548 NFS is typically used in local area network or enterprise settings, 1549 though changes made in later versions of NFS make it easier to 1550 operate over the Internet. 1552 5.3.1. Data Access Interface 1554 Traditional file-system operations such as read, write, and update 1555 (overwrite) are provided. Locking is provided to support concurrent 1556 access by multiple clients. 1558 5.3.2. Data Management Operations 1560 Traditional file-system operations such as move and delete are 1561 provided. 1563 5.3.3. Data Search Capability 1565 User has the ability to list contents of directories to find 1566 filenames matching desired criteria. 1568 5.3.4. Access Control Authorization 1570 All methods of access control for clients are supported: public- 1571 unrestricted, public-restricted and private. For example, files and 1572 directories can be protected using read, write, and execute 1573 permissions for the files owner, group, and the public (others). 1574 Also, NFSv4.1 has a rich ACL model allowing a list of Access Control 1575 Entries (ACEs) to be configured for each file or directory. The ACEs 1576 can specify per-user read/write access to file data, file/directory 1577 attributes, creation/deletion of files in a directory, etc. 1579 5.3.5. Resource Control Interface 1581 While disk space quotas can be configured, it typically limits the 1582 total amount of storage allocated to a particular user. User control 1583 of bandwidth and connections used by remote peers is not provided. 1585 5.3.6. Discovery Mechanism 1587 Manual configuration is typically used. Clients address NFS servers 1588 by providing a hostname and a directory that should be mounted. DNS 1589 may be used lookup an address for the provided hostname. 1591 5.3.7. Storage Mode 1593 As a protocol, there is no defined internal storage mode. However, 1594 implementations typically use the underlying filesystem storage. 1595 Note that extensions have been defined for alternate storage modes 1596 (e.g., block-based [34] and object-based [35]). 1598 5.3.8. Comments 1600 The efficiency and scalability of the NFS access control method is a 1601 concern in the context of DECADE. In particular, Section 6.2.1 of 1602 [33] states that: 1604 Only ACEs that have a "who" that matches the requester 1605 are considered. 1607 Thus, in the context of DECADE, to specify per-peer access control 1608 policies for an object, a client would need to explicitly configure 1609 the ACL for the object for each individual peer. A concern with this 1610 approach is scalability when a client's peers may change frequently 1611 and ACLs for many small objects need to be updated constantly during 1612 participation in a swarm. 1614 Note that NFS v4.1's usage of RPCSEC_GSS provides support for 1615 multiple security mechanisms. Kerberos V5 is required, but others 1616 such as X.509 certificates are also supported by way of GSS-API. 1617 Note, however, that NFSv4.1's usage of such security mechanisms is 1618 limited to linking a requesting user to a particular account 1619 maintained by the NFS server. 1621 5.4. OAuth 1623 OAuth [36] is a protocol that enriches the traditional client-server 1624 authentication model for web resources. In particular, OAuth 1625 distinguishes the "client" from the "resource owner", thus enabling a 1626 resource owner to authorize a particular client for access (e.g., for 1627 a particular lifetime) to private resources. 1629 We include OAuth in this survey so that its authentication model can 1630 be evaluated in the context of DECADE. OAuth itself, however, is not 1631 a network storage protocol. 1633 5.4.1. Data Access Interface 1635 Not provided. 1637 5.4.2. Data Management Operations 1639 Not provided. 1641 5.4.3. Data Search Capability 1643 Not provided. 1645 5.4.4. Access Control Authorization 1647 Not provided. While similar in spirit to the WebDAV ticketing 1648 extensions [37], OAuth instead uses the following process: (1) a 1649 client constructs a delegation request, (2) the client forwards the 1650 request to the resource owner for authorization, (3) the resource 1651 owner authorizes the request, and finally (4) a callback is made to 1652 the client indicating that its request has been authorized. 1654 Once the process is complete, the client has a set of token 1655 credentials that grant it access to the protected resource. The 1656 token credentials may have an expiration time, and they can also be 1657 revoked by the resource owner at any time. 1659 5.4.5. Resource Control Interface 1661 Not provided. 1663 5.4.6. Discovery Mechanism 1665 Not provided. 1667 5.4.7. Storage Mode 1669 Not provided. 1671 5.4.8. Comments 1673 The ticketing mechanism requires server involvement and the 1674 discussion relating to WebDAV's proposed ticketing mechanism (see 1675 Section 5.5.8) applies here as well. 1677 5.5. WebDAV 1679 WebDAV [38] is a protocol designed for Web content authoring. It is 1680 developed as an extension to HTTP described in Section 5.1, meaning 1681 it can be simpler to integrate into existing software. WebDAV 1682 supports traditional operations for reading/writing from storage, as 1683 well as other constructs such as locking and collections which are 1684 important when multiple users collaborate to author or edit a set of 1685 documents. 1687 5.5.1. Data Access Interface 1689 Traditional read and write operations are supported (using HTTP GET 1690 and PUT methods, respectively). Locking is provided to ease 1691 concurrent access by multiple clients. 1693 5.5.2. Data Management Operations 1695 WebDAV supports traditional file-system operations such as move, 1696 delete and copy. Objects are organized into collections, and these 1697 operations can also be performed on collections. WebDAV also allows 1698 objects to have user-defined properties. 1700 5.5.3. Data Search Capability 1702 User has the ability to list contents of collections to find objects 1703 matching desired criteria. A SEARCH extension [39] has also been 1704 specified allowing listing of objects matching client-defined 1705 criteria. 1707 5.5.4. Access Control Authorization 1709 All methods of access control for clients are supported: public- 1710 unrestricted, public-restricted and private. 1712 For example, an ACL extension [40] is provided for WebDAV. ACLs 1713 allow both user- and group-based access control policies (relating to 1714 reading, writing, properties, locking, etc) to be defined for objects 1715 and collections. 1717 A ticketing extension [37] has also been proposed, but has not 1718 progressed beyond an Internet Draft. This extension allows a client 1719 to request the WebDAV server to create a "ticket" (e.g., for reading 1720 an object) that can be distributed to other clients. Tickets may be 1721 given expiration times, or may only allow for a fixed number of uses. 1722 The proposed extension requires the server to generate tickets and 1723 maintain state for outstanding tickets. 1725 5.5.5. Resource Control Interface 1727 An extension [41] allows disk space quotas to be configured for 1728 Collections. The extension also allows WebDAV clients to query 1729 current disk space usage. User control of bandwidth and connections 1730 used by remote peers is not provided. 1732 5.5.6. Discovery Mechanism 1734 Manual configuration is typically used. Clients address WebDAV 1735 servers by providing a hostname, which can be resolved to an address 1736 using DNS. 1738 5.5.7. Storage Mode 1740 Though no storage mode is explicitly defined, WebDAV can be thought 1741 of as providing file-based storage to a client. A non-collection 1742 resource can typically be thought of as a "file". Files may be 1743 organized into collections, which typically map on to the HTTP Path 1744 hierarchy. 1746 5.5.8. Comments 1748 The efficiency and scalability of the WebDAV access control method is 1749 a concern in the context of DECADE, for similar reasons as stated in 1750 Section 5.3.8 for NFS. The proposed WebDAV ticketing extension 1751 partially alleviates this concern, but the particular technique may 1752 need further evaluation before being applied to DECADE. In 1753 particular, since DECADE clients may continuously upload/download a 1754 large number of small-size objects, and a single DECADE server may 1755 need to scale to many concurrent DECADE clients, requiring the server 1756 to maintain ticket state and generate tickets may not be the best 1757 design choice. Server-generated tickets can also increase latency 1758 for data transport operations depending on the message flow used by 1759 DECADE. 1761 5.6. Observations Regarding Storage and Related Protocols 1763 This following observations about the surveyed storage and related 1764 protocols are made in the context of DECADE as defined by [1]. 1766 All of the surveyed protocols were primarily designed for client- 1767 server architectures and not for P2P. However, it is conceivable that 1768 some of the protocols could be adapted to work in a P2P architecture. 1770 Several popular in-network storage systems today use HTTP as their 1771 key protocol even though it is not classically considered as a 1772 storage protocol. HTTP is a stateless protocol that is used to 1773 design RESTful applications. HTTP is a well supported and widely 1774 implemented protocol which can provide important insights for DECADE. 1776 The majority of the surveyed protocols do not support low latency 1777 access for applications such as live streaming. This was one of the 1778 key general requirements for DECADE. 1780 The majority of the surveyed protocols do not support any form of 1781 resource control interface. Resource control is required for users 1782 to manage the resources on in-network storage that can be used by 1783 other peers, e.g., the bandwidth or connections. Resource control is 1784 a key capability required for DECADE. 1786 Nearly all surveyed protocols did however support the following 1787 capabilities which are required for DECADE: user ability to read/ 1788 write content; some form of access control; some form of error 1789 indication; and ability to traverse firewalls and NATs. 1791 6. Conclusions 1793 Though there have been many successful in-network storage systems, 1794 they have been designed for use cases different from those defined in 1795 DECADE. For example, many of the surveyed in-network storage systems 1796 and protocols were designed for client-server architectures and not 1797 P2P. No surveyed system or protocol has the functionality and 1798 features to fully meet the set of requirements defined for DECADE. 1799 DECADE aims to provide a standard protocol for P2P applications and 1800 content provider to access and control in-network storage, resulting 1801 in increased network efficiency while retaining control over content 1802 shared with peers. Additionally, defining a standard protocol can 1803 reduce complexity of in-network storage since multiple P2P 1804 application protocols no longer need to be implemented by in-network 1805 storage systems. 1807 7. Security Considerations 1809 This draft is a survey of existing in-network storage systems, and 1810 does not introduce any security considerations beyond those of the 1811 surveyed systems. 1813 For more information on security considerations of DECADE, see [1]. 1815 8. IANA Considerations 1817 This document does not have any IANA Considerations. 1819 9. Contributors 1821 The editors would like to thank the following people for contributing 1822 to the development of this document: 1824 - ZhiHui Lu 1826 - Borje Ohlman 1828 - Pang Tao 1830 - Lucy Yong 1832 - Juan Carlos Zuniga 1834 10. Acknowledgments 1836 The editors would like to thank the following people for providing 1837 valuable comments to various versions of this document: David Bryan, 1838 Tao Mao, Haibin Song, Ove Strandberg, Yu-Shun Wang, Richard Woundy, 1839 Yunfei Zhang, and Ning Zong. 1841 11. Informative References 1843 [1] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 1844 Application Data Enroute (DECADE) Problem Statement", 1845 draft-ietf-decade-problem-statement-03 (work in progress), 1846 March 2011. 1848 [2] Storage Search, "Flash Memory vs. Hard Disk Drives - Which Will 1849 Win?", http://www.storagesearch.com/semico-art1.html. 1851 [3] Matt's Computer Trends, "Flash and Disk Trends", 1852 http://www.mattscomputertrends.com/flashdiskcomparo.html. 1854 [4] Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE 1855 Requirements", draft-ietf-decade-reqs-03 (work in progress), 1856 July 2011. 1858 [5] Amazon, "Amazon Simple Storage Service (Amazon S3)", 1859 http://aws.amazon.com/s3/. 1861 [6] Microsoft Corporation, "Windows Azure Blob - Programming Blob 1862 Storage". 1864 [7] Google, "Google Storage for Developers", 1865 http://code.google.com/apis/storage. 1867 [8] Dropbox, "Dropbox Features", http://www.dropbox.com/features. 1869 [9] Microsoft Corporation, "BranchCache", 1870 http://technet.microsoft.com/en-us/network/dd425028.aspx. 1872 [10] S. Paul, R. Yates, D. Raychaudhuri, J. Kurose., "The Cache-and- 1873 Forward Network Architecture for Efficient Mobile Content 1874 Delivery Services in the Future Internet", In Innovations in 1875 NGN: Future Network and Services, 2008. 1877 [11] SNIA, "Cloud Data Management Interface", 1878 http://www.snia.org/cdmi. 1880 [12] Pathan, A.K., Buyya, R., "A Taxonomy and Survey of Content 1881 Delivery Networks", In Grid Computing and Distributed Systems 1882 Laboratory in University of Melbourne, Technology Report, Feb. 1883 2007. 1885 [13] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., 1886 Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking 1887 Architecture", RFC 4838, April 2007. 1889 [14] Scott, K. and S. Burleigh, "Bundle Protocol Specification", 1890 RFC 5050, November 2007. 1892 [15] Named Data Networking, "Named Data Networking Home Page", 1893 http://www.named-data.net/. 1895 [16] Named Data Networking, "Named Data Networking Project 1896 Proposal", http://www.named-data.net/ndn-proj.pdf. 1898 [17] Network of Information., "Network of Information Overview", 1899 http://www.netinf.org/home/overview/. 1901 [18] A. Anand, V. Sekar, A. Akella., "SmartRE: An Architecture for 1902 Coordinated Network-wide Redundancy Elimination", In SIGCOMM 1903 2009. 1905 [19] S. Rhea, P. Eaton, D. Geels, H. Weatherspoon, B. Zhao, and J. 1906 Kubiatowicz., "Pond: the OceanStore Prototype", In FAST 2003. 1908 [20] Kodak, "Kodak Gallery Home Page", 1909 http://www.kodakgallery.com/gallery/welcome.jsp. 1911 [21] Wikipedia, "Kodak Gallery", 1912 http://en.wikipedia.org/wiki/Kodak_Gallery. 1914 [22] Flickr, "Flickr Home Page", http://www.flickr.com. 1916 [23] ImageShack, "ImageShack Home Page", http://imageshack.us. 1918 [24] Tumblr, "Tumblr Home Page", http://www.tumblr.com. 1920 [25] Wikipedia, "Usenet", http://en.wikipedia.org/wiki/Usenet. 1922 [26] Google, "Google Groups", http://groups.google.com. 1924 [27] Geoff Huston, Telstra., "Web Caching", In The Internet Protocol 1925 Journal Volume 2, No. 3. 1927 [28] G. Shen, Y. Wang, Y. Xiong, B.Y. Zhao, Z.-L. Zhang, "HPTP: 1928 Relieving the tension between isps and p2p", In 6th 1929 International workshop on Peer-To-Peer Systems (IPTPS2007). 1931 [29] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1932 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1933 HTTP/1.1", RFC 2616, June 1999. 1935 [30] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. 1936 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 1937 RFC 3720, April 2004. 1939 [31] Simpson, W., "PPP Challenge Handshake Authentication Protocol 1940 (CHAP)", RFC 1994, August 1996. 1942 [32] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. 1943 Souza, "Internet Storage Name Service (iSNS)", RFC 4171, 1944 September 2005. 1946 [33] Shepler, S., Eisler, M., and D. Noveck, "Network File System 1947 (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, 1948 January 2010. 1950 [34] Black, D., Fridella, S., and J. Glasgow, "Parallel NFS (pNFS) 1951 Block/Volume Layout", RFC 5663, January 2010. 1953 [35] Halevy, B., Welch, B., and J. Zelenka, "Object-Based Parallel 1954 NFS (pNFS) Operations", RFC 5664, January 2010. 1956 [36] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 1957 April 2010. 1959 [37] Ito, K., "Ticket-Based Access Control Extension to WebDAV", 1960 draft-ito-dav-ticket-00 (work in progress), October 2001. 1962 [38] Dusseault, L., "HTTP Extensions for Web Distributed Authoring 1963 and Versioning (WebDAV)", RFC 4918, June 2007. 1965 [39] Reschke, J., Reddy, S., Davis, J., and A. Babich, "Web 1966 Distributed Authoring and Versioning (WebDAV) SEARCH", 1967 RFC 5323, November 2008. 1969 [40] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 1970 Distributed Authoring and Versioning (WebDAV) 1971 Access Control Protocol", RFC 3744, May 2004. 1973 [41] Korver, B. and L. Dusseault, "Quota and Size Properties 1974 for Distributed Authoring and Versioning (DAV) Collections", 1975 RFC 4331, February 2006. 1977 Authors' Addresses 1979 Richard Alimi (editor) 1980 Google 1982 Email: ralimi@google.com 1984 Akbar Rahman (editor) 1985 InterDigital Communications, LLC 1987 Email: Akbar.Rahman@InterDigital.com 1989 Yang Richard Yang (editor) 1990 Yale University 1992 Email: yry@cs.yale.edu