Internet Engineering Task Force (IETF) R. Alimi, Ed. Request for Comments: 6392 Google Category: Informational A. Rahman, Ed. ISSN: 2070-1721 InterDigital Communications, LLC Y. Yang, Ed. Yale University October 2011 A Survey of In-Network Storage Systems
AbstractThis document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupled Application Data Enroute) architecture. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6392. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction ....................................................3 2. Survey Overview .................................................3 2.1. Terminology and Concepts ...................................3 2.2. Historical Context .........................................3 3. In-Network Storage System Components ............................5 3.1. Data Access Interface ......................................5 3.2. Data Management Operations .................................5 3.3. Data Search Capability .....................................6 3.4. Access Control Authorization ...............................6 3.5. Resource Control Interface .................................6 3.6. Discovery Mechanism ........................................7 3.7. Storage Mode ...............................................7 4. In-Network Storage Systems ......................................7 4.1. Amazon S3 ..................................................7 4.2. BranchCache ................................................9 4.3. Cache-and-Forward Architecture ............................11 4.4. Cloud Data Management Interface ...........................12 4.5. Content Delivery Network ..................................14 4.6. Delay-Tolerant Network ....................................16 4.7. Named Data Networking .....................................18 4.8. Network of Information ....................................19 4.9. Network Traffic Redundancy Elimination ....................22 4.10. OceanStore ...............................................23 4.11. P2P Cache ................................................24 4.12. Photo Sharing ............................................26 4.13. Usenet ...................................................28 4.14. Web Cache ................................................29 4.15. Observations Regarding In-Network Storage Systems ........31 5. Storage and Other Related Protocols ............................32 5.1. HTTP ......................................................32 5.2. iSCSI .....................................................33 5.3. NFS .......................................................34 5.4. OAuth .....................................................36 5.5. WebDAV ....................................................37 5.6. Observations Regarding Storage and Related Protocols ......39 6. Conclusions ....................................................40 7. Security Considerations ........................................40 8. Contributors ...................................................40 9. Acknowledgments ................................................41 10. Informative References ........................................41
1] for further discussion. A major motivation for DECADE is the substantial increase in capacity and reduction in cost offered by storage systems. For example, over the last two decades, there has been at least a 30-fold increase in the amount of storage that a customer can get for a given price (for flash memory and hard disk drives)   . High-capacity and low-cost in-network storage devices introduce substantial opportunities. One example of in-network storage is content caches supporting Web and P2P content. DECADE differs from existing content caches whose control fully resides with the owners of the caching devices in that DECADE also allows applications to control access to their allocated in-network storage, as well as the resources consumed while accessing that storage (bandwidth, connections, storage space). While designed in the context of P2P applications, DECADE may be useful to other applications as well. This document provides details on deployed and experimental in-network storage solutions, and evaluates their suitability for DECADE. We note that the survey presented in this document is only representative of the research in this area. Rather than trying to enumerate an exhaustive list, we have chosen some typical techniques that lead to derivative works. 1].
approaches. Systems have been developed with particular use cases in mind. Thus, this survey is not meant to point out shortcomings of existing solutions, but rather to indicate where certain capabilities required in DECADE  are not provided by existing systems. In the early stage of Internet development, most Web content was stored at a central server, and clients requested Web content from the central server. In this architecture, the central server was required to provide a large amount of bandwidth. As more and more users access Web content, a central server can become overloaded. The use of Web caches is one technique to reduce load on a central server. Web caches store frequently requested content and provide bandwidth for serving the content to clients. The ongoing growth of broadband technology in the worldwide market has been driven by the hunger of customers for new multimedia services as well as Web content. In particular, the use of audio and video streaming formats has become common for delivery of rich information to the public, both residential and business. To overcome this challenge of massive multimedia consumption, just installing more Web caches will not be enough. Moving content closer to the consumer results in greater network efficiency, improved Quality of Service (QoS), and lower latency, while facilitating personalization of content through broadband content applications. In these edge technologies, Content Delivery Networks (CDNs) are a representative technique. CDNs are based on a large-scale distributed network of servers located closer to customers for efficient delivery of digital content, including various forms of multimedia content. Although CDNs are an effective means of information access and delivery, there are two barriers to making CDNs a more common service: cost and replication integrity. Deploying a CDN with its associated infrastructure is expensive. A CDN also requires administrative control over nodes with large storage capacity at geographically dispersed locations with adequate connectivity. CDNs can be scalable, but due to this administrative and cost overhead, they are not rapidly deployable for the common user. The emergence and maturation of P2P has allowed improvements to many network applications. P2P allows the use of client resources, such as CPU, memory, storage, and bandwidth, for serving content. This can reduce the amount of resources required by a content provider. Multimedia content delivery using various P2P or peer-assisted frameworks has been shown to greatly reduce the dependence on CDNs and central content servers. However, the popularity of P2P applications has resulted in increased traffic on ISP networks. P2P
caches (both transparent and non-transparent) have been introduced as a way to reduce the burden. Though they can be effective in reducing traffic in certain areas of ISP networks, P2P caches have their shortcomings. In particular, they are application-dependent and thus difficult to keep up to date with new and evolving P2P application protocols. Second, applications may benefit from explicit control of in-network storage, which P2P caches do not provide. See  for further discussion. DECADE aims to provide a standard protocol allowing P2P applications (including content providers) to make use of in-network storage to reduce the traffic burden on ISP networks, while enabling P2P applications to control access to content they have placed in in-network storage.
6] provides an online storage service using Web (HTTP) interfaces. Users create buckets, and each bucket can contain stored objects. Users are provided an interface
10] is a feature integrated into Windows (Windows 7 and Windows Server 2008R2) that aims to optimize enterprise branch office file access over WAN links. The main goals are to reduce WAN link utilization and improve application responsiveness by caching and sharing content within a branch while still maintaining end-to-end security. BranchCache allows files retrieved from the Web servers and file servers located in headquarters or data centers to be cached in remote branch offices, and shared among users in the same branch accessing the same content. BranchCache operates transparently by instrumenting the HTTP and Server Message Block (SMB) components of the networking stack. It provides two modes of operation: Distributed Cache and Hosted Cache. In both modes, a client always contacts a BranchCache-enabled content server first to get the content identifiers for local search. If the content is cached locally, the client then retrieves the content within the branch. Otherwise, the client will go back to the original content server to request the content. The two modes differ in how the content is shared. In the Hosted Cache mode, a locally provisioned server acts as a cache for files retrieved from the servers. After getting the content identifiers, the client first consults the cache for the desired file. If it is not present in the cache, the client retrieves it from the content server and sends it to the cache for storage. In the Distributed Cache mode, a client first queries other clients in the same network using the Web Services Discovery multicast protocol . As in the Hosted Cache mode, the client retrieves the file from the content server if it is not available locally. After retrieving the file (either from another client or the content server), the client stores the file locally.
The original content server always authorizes requests from clients. Cached content is encrypted such that clients can decrypt the data only using keys derived from metadata returned by the content server. In addition to instrumenting the networking stack at clients, content servers must also support BranchCache.
12] is an architecture for content delivery services for the future Internet. In this architecture, storage can be exploited on nodes within the network, either directly on routers or deployed near the routers. CNF is based on the concept of store- and-forward routers with large storage, providing for opportunistic delivery to occasionally disconnected mobile users and for in-network caching of content. The proposed CNF protocol uses reliable hop-by- hop transfer of large data files between CNF routers in place of an end-to-end transport protocol such as TCP.
13]. CDMI follows a traditional client-server model, and operates over an HTTP interface using the Representational State Transfer (REST) model. Similar to Amazon S3 buckets (see Section 4.1), users may create containers in which data objects may be stored. Even though data objects may be accessed via a user-defined name within a container, it is also possible to access data objects via a storage- defined Object ID, which is provided in the response upon creation of a data object.
14] for an additional taxonomy and survey. A CDN has some combination of content delivery, request routing, distribution, and accounting infrastructures. The content-delivery infrastructure consists of a set of edge servers (also called surrogates) that deliver copies of content to end users. The request-routing infrastructure is responsible for directing client requests to appropriate edge servers. It also interacts with the distribution infrastructure to keep an up-to-date view of the content stored in the CDN caches. The distribution infrastructure moves content from the origin server to the CDN edge servers and ensures consistency of content in the caches. The accounting infrastructure maintains logs of client accesses and records the usage of the CDN servers. This information is used for traffic reporting and usage- based billing. In practice, a CDN typically hosts static content including images, video, media clips, advertisements, and other embedded objects for Web viewing. A focus for CDNs is the ability to publish and deliver content to end users in a reliable and timely manner. A CDN focuses on building its network infrastructure to provide the following services and functionalities: storage and management of content; distribution of content among surrogates; cache management; delivery of static, dynamic, and streaming content; backup and disaster recovery solutions; and monitoring, performance measurement, and reporting. Examples of existing CDNs are Akamai, Limelight, and CloudFront.
The following description uses the term "content provider" to refer to the entity purchasing a CDN service, and the term "client" to refer to the subscriber requesting content via the CDN from the content provider.
15] is an evolution of an architecture originally designed for the Interplanetary Internet. The Interplanetary Internet is a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. The DTN architecture can be utilized in various operational environments characterized by severe communication disruptions, disconnections, and high delays (e.g., a month-long loss of connectivity between two planetary networks because of high solar radiation due to sun spots). The DTN architecture is thus suitable for environments including deep space networks, sensor-based networks, certain satellite networks, and underwater acoustic networks. A key aspect of the DTN is a store-and-forward overlay layer called the "Bundle Protocol" or "Bundle Layer", which exists between the transport and application layers . The Bundle Layer forms a logical overlay that employs persistent storage to help combat long- term network interruptions by providing a store-and-forward service. While traditional IP networks are also based on store-and-forward principles, the amount of time of a packet being kept in "storage" at a traditional IP router is typically on the order of milliseconds (or less). In contrast, the DTN architecture assumes that most Bundle Layer nodes will use some form of persistent storage (e.g., hard disk, flash memory, etc.) for DTN packets because of the nature of the DTN environment.
17] is a research initiative that proposes to move to a new model of addressing and routing for the Internet. NDN uses "named data"-based routing and forwarding, to replace the current IP-address-based model. NDN also uses name-based data caching in the routers. Each NDN Data packet will be assigned a content name and will be cryptographically signed. Data delivery is driven by the requesting end. Routers disseminate name-based prefix announcements by using routing protocols such as Intermediate System to Intermediate System (IS-IS) or the Border Gateway Protocol (BGP). The requester will send out an "Interest" packet, which identifies the name of the data that it wants. Routers that receive this Interest packet will remember the interface it came from and will then forward it on a name-based routing protocol. Once an Interest packet reaches a node that has the desired data, a named Data packet is sent back, which carries both the name and content of the data, along with a digital signature of the producer. This named Data packet is then forwarded back to the original requester on the reverse path of the Interest packet . A key aspect of NDN is that routers have the capability to cache the named data. If a request for the same data (i.e., same name) comes to the router, then the NDN router will forward the named data stored locally to fulfill the request. The proponents of NDN believe that the network can be designed naturally, matching data delivery characteristics instead of communication between endpoints, because data delivery has become the primary use of the network.
Section 4.7), Network of Information (NetInf)  is another information-centric approach in which the named data objects are the basic component of the networking architecture. NetInf is thus moving away from today's host-centric networking
architecture where the nodes in the network are the primary objects. In today's network, the information objects are named relative to the hosts they are stored on (e.g., http://www.example.com/information-object.txt). The NetInf naming and security framework builds the foundation for an information-centric security model that integrates security deeply into the architecture. In this model, trust is based on the information itself. Information objects (IOs) are given a unique name with cryptographic properties. Together with additional metadata, the name can be used to verify the data integrity as well as several other security properties, such as self-certification, name persistency, and owner authentication and identification. The approach also gives some benefits over the security model in today's host-centric networks, as it minimizes the need for trust in the infrastructure, including the hosts providing the data, the channel, or the resolution service. In NetInf, the information objects are published into the network. They are registered with a Name Resolution Service (NRS). The NRS is also used to register network locators that can be used to retrieve data objects that represent the published IOs. When a receiver wants to retrieve an IO, the request for the IO is resolved by the NRS into a set of locators. These locators are then used to retrieve a copy of the data object from the "best" available source(s). NetInf is open to use any type of underlying transport network. The locators can thus be a heterogeneous set, e.g., IPv4, IPv6, Medium Access Control (MAC), etc. NetInf will make extensive use of caching of information objects in the network and will provide network functionality that is similar to what overlay solutions such as CDNs and P2P distribution networks (e.g., BitTorrent) provide today.
20], proposed by Anand et al., which focuses on network-wide RE. In packet-level RE, forwarding elements are equipped with additional storage that can be used to cache data from forwarded packets. Upstream routers may replace packet data with a fingerprint that tells a downstream router how to decode and reconstruct the packet based on cached data.
21] is a storage platform developed at the University of California, Berkeley, that provides globally distributed storage. OceanStore implements a model where multiple storage providers can pool resources together. Thus, a major focus is on resiliency, self- organization, and self-maintenance. The protocol is resilient to some storage nodes being compromised by utilizing Byzantine agreement and erasure codes to store data at primary replicas.
Section 4.14) in that they temporarily store frequently requested content. Requests for content already stored in the cache can be served from local storage instead of requiring the data to be transmitted over expensive network links. Two types of P2P caches exist: transparent P2P caches and non-transparent P2P caches. For a transparent cache, once a P2P cache is established, the network will transparently redirect P2P traffic to the cache, which either serves the file directly or passes the request on to a remote P2P user and simultaneously caches that data. Transparency is typically implemented using Deep Packet Inspection (DPI). DPI products identify and pass P2P packets to the P2P caching system so it can cache and accelerate the traffic. A non-transparent cache appears as a super peer; it explicitly peers with other P2P clients. To enable operation with existing P2P software, P2P caches directly support P2P application protocols. A large number of P2P protocols are used by P2P software and hence are supported by caches, leading to higher complexity. Additionally, these protocols evolve over time, and new protocols are introduced.
services, such as Tumblr , that specialize in sharing large numbers of photos as well as other multimedia content (e.g., video, text, audio, etc.) as part of their service. All of these in-network storage systems utilize both free and paid subscription models. Most photo-sharing systems are based on a traditional client-server architecture. However, a minority of systems also offer a P2P mode of operation. The client-server architecture is typically based on HTTP, with a browser client and a Web server.
27]. Traditional Usenet as described above operates as a P2P network between the servers, and in a client-server architecture between the user and their local news server. The user requires a Usenet client to be installed on their computer and a Usenet server account (through their ISP). However, with the rise of Web browsers, the Usenet architecture is evolving to be Web-based. The most popular example of this is Google Groups, where Google hosts all the newsgroups and client access is via a standard HTTP-based Web browser .
29] has been widely deployed by many ISPs to reduce bandwidth consumption and Web access latency since the late 1990s. A Web cache can cache the Web documents (e.g., HTML pages, images) between server and client to reduce bandwidth usage, server load, and perceived lag. A Web cache server is typically shared by many clients, and stores copies of documents passing through it; subsequent requests may be satisfied from the cache if certain conditions are met. Another form of cache is a client-side cache, typically implemented in Web browsers. A client-side cache can keep a local copy of all pages recently displayed by a browser, and when the user returns to one of these Web pages, the local cached copy is reused.
A related protocol for P2P applications to use Web cache is HPTP (HTTP-based Peer to Peer) . It proposes sharing chunks of P2P files/streams using HTTP with cache-control headers.
1]. The majority of the surveyed systems were designed for client-server architectures and do not support P2P. However, there are some important exceptions, especially for some of the newer technologies such as BranchCache and P2P cache, that do support a P2P mode of operation. The P2P cache systems are interesting, since they do not require changes to the P2P applications themselves. However, this is also a limitation in that they are required to support each application protocol. Many of the surveyed systems were designed for caching as opposed to long-term network storage. Thus, during DECADE protocol design, it should be carefully considered whether a caching mode should be supported in addition to a long-term network storage mode. There is typically a trade-off between providing a caching mode and long-term (and usually also reliable) storage with regards to some performance metrics. Note that  identifies issues with classical caching from a DECADE perspective, such as the fact that P2P caches typically do not allow users to explicitly control content stored in the cache. Certain components of the surveyed systems are outside of the scope of DECADE. For example, a protocol used for searching across multiple DECADE servers is out of scope. However, applications may still be able to implement such functionality if DECADE exposes the appropriate primitives. This has the benefit of keeping the core in-network storage systems simple, while permitting diverse applications to design mechanisms that meet their own requirements. Today, most in-network storage systems follow some variant of the authorization model of public-unrestricted, public-restricted, and private. For DECADE, we may need to evolve the authorization model to support a resource owner (e.g., end user) authorization, in addition to the network authorization.
31] is a key protocol for the World Wide Web. It is a stateless client-server protocol that allows applications to be designed using the REST model. HTTP is often associated with downloading (reading) content from Web servers to Web browsers, but it also has support for uploading (writing) content to Web servers. It has been used as the underlying protocol for other protocols, such as Web Distributed Authoring and Versioning (WebDAV). HTTP is used in some of the most popular in-network storage systems surveyed previously, including CDNs, photo sharing, and Web cache. Usage of HTTP by a storage protocol implies that no extra software is required in the client (i.e., Web-based client), as all standard Web browsers are based on HTTP. Section 4.12.5) to public-unrestricted for Web caching (described in Section 4.14.5).
32] is a protocol enabling SCSI commands to be sent over TCP. As in SCSI, iSCSI allows an Initiator to send commands to a Target. These commands operate on the device level as opposed to individual data objects stored on the device.
33] to authenticate Initiators and Targets when accessing storage devices. However, since SCSI/iSCSI operates at the device level, neither authentication nor authorization is provided for individual data objects. Note that such capabilities can be implemented outside of iSCSI. 34], which provides the ability to discover available storage resources. 35]) make it easier to operate over the Internet.
Section 6.2.1 of  states that: Only ACEs that have a "who" that matches the requester are considered. Thus, in the context of DECADE, to specify per-peer access control policies for an object, a client would need to explicitly configure the ACL for the object for each individual peer. A concern with this approach is scalability when a client's peers may change frequently, and ACLs for many small objects need to be updated constantly during participation in a swarm. Note that NFSv4.1's usage of RPCSEC_GSS provides support for multiple security mechanisms. Kerberos V5 is required, but others, such as X.509 certificates, are also supported by way of the Generic Security Service Application Program Interface (GSS-API). Note, however, that NFSv4.1's usage of such security mechanisms is limited to linking a requesting user to a particular account maintained by the NFS server. 38] is a protocol that enriches the traditional client-server authentication model for Web resources. In particular, OAuth distinguishes the "client" from the "resource owner", thus enabling a resource owner to authorize a particular client for access (e.g., for a particular lifetime) to private resources. We include OAuth in this survey so that its authentication model can be evaluated in the context of DECADE. OAuth itself, however, is not a network storage protocol.
39], OAuth instead uses the following process: (1) a client constructs a delegation request, (2) the client forwards the request to the resource owner for authorization, (3) the resource owner authorizes the request, and finally (4) a callback is made to the client indicating that its request has been authorized. Once the process is complete, the client has a set of token credentials that grant it access to the protected resource. The token credentials may have an expiration time, and they can also be revoked by the resource owner at any time. Section 5.5.8) applies here as well. 40] is a protocol designed for Web content authoring. It is developed as an extension to HTTP (described in Section 5.1), meaning that it can be simpler to integrate into existing software. WebDAV supports traditional operations for reading/writing from storage, as well as other constructs, such as locking and collections, that are important when multiple users collaborate to author or edit a set of documents.
41] has also been specified allowing listing of objects matching client-defined criteria. 42] is provided for WebDAV. ACLs allow both user-based and group-based access control policies (relating to reading, writing, properties, locking, etc.) to be defined for objects and collections. A ticketing extension  has also been proposed, but has not progressed since 2001. This extension allows a client to request the WebDAV server to create a "ticket" (e.g., for reading an object) that can be distributed to other clients. Tickets may be given expiration times, or may only allow for a fixed number of uses. The proposed extension requires the server to generate tickets and maintain state for outstanding tickets. 43] allows disk space quotas to be configured for collections. The extension also allows WebDAV clients to query current disk space usage. User control of bandwidth and connections used by remote peers is not provided.
Section 5.3.8 for NFS. The proposed WebDAV ticketing extension partially alleviates these concerns, but the particular technique may need further evaluation before being applied to DECADE. In particular, since DECADE clients may continuously upload/download a large number of small-size objects, and a single DECADE server may need to scale to many concurrent DECADE clients, requiring the server to maintain ticket state and generate tickets may not be the best design choice. Server-generated tickets can also increase latency for data transport operations, depending on the message flow used by DECADE. 1]. All of the surveyed protocols were primarily designed for client- server architectures and not for P2P. However, it is conceivable that some of the protocols could be adapted to work in a P2P architecture. Several popular in-network storage systems today use HTTP as their key protocol, even though it is not classically considered as a storage protocol. HTTP is a stateless protocol that is used to design RESTful applications. HTTP is a well-supported and widely implemented protocol that can provide important insights for DECADE. The majority of the surveyed protocols do not support low-latency access for applications such as live streaming. This was one of the key general requirements for DECADE. The majority of the surveyed protocols do not support any form of resource control interface. Resource control is required for users to manage the resources on in-network storage systems, e.g., the bandwidth or connections, that can be used by other peers. Resource control is a key capability required for DECADE.
Nearly all surveyed protocols did, however, support the following capabilities required for DECADE: ability of the user to read/write content, some form of access control, some form of error indication, and the ability to traverse firewalls and NATs. 1].
 Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", Work in Progress, October 2011.  Storage Search, "Flash Memory vs. Hard Disk Drives -- Which Will Win?", <http://www.storagesearch.com/semico-art1.html>.  Brisken, W., "Hard Drive Price Trends", US VLBI Technical Meeting, May 2008.  Woundy, R., "TSV P2P Efforts -- From an ISP's Perspective", IETF 81, Quebec, Canada, July 2011, <http://www.ietf.org/proceedings/81/slides/tsvarea-3.pdf>.  Gu, Y., Bryan, D., Yang, Y., and R. Alimi, "DECADE Requirements", Work in Progress, September 2011.  Amazon Web Services, "Amazon Simple Storage Service (Amazon S3)", <http://aws.amazon.com/s3/>.  Calder, B., Wang, T., Mainali, S., and J. Wu, "Windows Azure Blob -- Programming Blob Storage", May 2009, <http://www.microsoft.com/windowsazure/whitepapers/>.  Google, "Google Storage for Developers", <http://code.google.com/apis/storage>.  Dropbox, "Dropbox Features", <http://www.dropbox.com/features>.  Microsoft Corporation, "BranchCache", <http://technet.microsoft.com/en-us/network/dd425028.aspx>.  Microsoft Corporation, "Web Services Dynamic Discovery (WS-Discovery)", April 2005, <http://specs.xmlsoap.org/ ws/2005/04/discovery/ws-discovery.pdf>.
 Paul, S., Yates, R., Raychaudhuri, D., and J. Kurose, "The Cache-and-Forward Network Architecture for Efficient Mobile Content Delivery Services in the Future Internet", Innovations in NGN: Future Network and Services, 2008.  SNIA, "Cloud Data Management Interface (CDMI)", <http://www.snia.org/cdmi>.  Pathan, A.K. and Buyya, R., "A Taxonomy and Survey of Content Delivery Networks", Grid Computing and Distributed Systems Laboratory, University of Melbourne, Technical Report, February 2007.  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007.  Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.  Named Data Networking, "Named Data Networking Home Page", <http://www.named-data.net/>.  Named Data Networking, "Named Data Networking (NDN) Project", <http://www.named-data.net/ndn-proj.pdf>.  Network of Information, "NetInf Overview", <http://www.netinf.org/home/overview/>.  Anand, A., Sekar, V., and A. Akella, "SmartRE: An Architecture for Coordinated Network-wide Redundancy Elimination", SIGCOMM 2009.  Rhea, S., Eaton, P., Geels, D., Weatherspoon, H., Zhao, B., and J. Kubiatowicz, "Pond: the OceanStore Prototype", FAST 2003.  Kodak, "Kodak Gallery Home Page", <http://www.kodakgallery.com/gallery/welcome.jsp>.  Wikipedia, "Kodak Gallery", <http://en.wikipedia.org/wiki/Kodak_Gallery>.  Flickr, "Flickr Home Page", <http://www.flickr.com>.  ImageShack, "ImageShack Home Page", <http://imageshack.us>.  Tumblr, "Tumblr Home Page", <http://www.tumblr.com>.
 Wikipedia, "Usenet", <http://en.wikipedia.org/wiki/Usenet>.  Google, "Google Groups", <http://groups.google.com>.  Huston, G., Telstra, "Web Caching", The Internet Protocol Journal Volume 2, No. 3.  Shen, G., Wang, Y., Xiong, Y., Zhao, B., and Z-L. Zhang, "HPTP: Relieving the Tension between ISPs and P2P", 6th International Workshop on Peer-To-Peer Systems (IPTPS2007).  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.  Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.  Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.  Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.  Black, D., Fridella, S., and J. Glasgow, "Parallel NFS (pNFS) Block/Volume Layout", RFC 5663, January 2010.  Halevy, B., Welch, B., and J. Zelenka, "Object-Based Parallel NFS (pNFS) Operations", RFC 5664, January 2010.  Hammer-Lahav, E., Ed., "The OAuth 1.0 Protocol", RFC 5849, April 2010.  Ito, K., "Ticket-Based Access Control Extension to WebDAV", Work in Progress, October 2001.  Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.  Reschke, J., Ed., Reddy, S., Davis, J., and A. Babich, "Web Distributed Authoring and Versioning (WebDAV) SEARCH", RFC 5323, November 2008.
 Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.  Korver, B. and L. Dusseault, "Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections", RFC 4331, February 2006.