RFC 6392

A Survey of In-Network Storage Systems

📅 published October 2011, from ietf

RFC 6392: A Survey of In-Network Storage Systems 🦋

okay bestie, RFC 6392 is an Internet Engineering Task Force (IETF) doc called A Survey of In-Network Storage Systems 💅 It came out in October 2011 📅 Its category is Informational, and its ISSN is 2070-1721. The editors are R. Alimi (Google), A. Rahman (InterDigital Communications, LLC), and Y. Yang (Yale University), each credited as Ed. 🎀 Nothing in the header says it obsoletes or updates another RFC, so it's standing on its own ✨

Abstract 🌸

this doc surveys deployed and experimental in-network storage systems and describes how well they fit the DECADE (DECoupled Application Data Enroute) architecture 🧚

Status of This Memo 💜

this one is not an Internet Standards Track spec. It's published for informational purposes, so it's more of a "here's what's out there" moment than a rulebook 📚

It's a product of the IETF, which means it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🙈

For the current status, errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6392 🔥

Copyright Notice 🌈

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they were in effect when this was published. Read those carefully, because they spell out your rights and restrictions for this doc 🙏 If you pull Code Components out of this document, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. They also come with no warranty, as the Simplified BSD License describes 🧃

Table of Contents 🎀

   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. Introduction ✨

okay so DECADE (DECoupled Application Data Enroute) is an architecture that gives applications access to provider-based in-network storage for content distribution. From here on I'll just say "in-network storage" 💅 Apps with that kind of access can be designed to put less load on network infrastructure. Simple example: a peer in a Peer-to-Peer (P2P) app can upload to other peers through its in-network storage, which saves its last-mile uplink bandwidth 🫶 See [1] for more.

the big motivation is that storage systems have gotten way more capacity for way less money 📈 Over the last two decades, a customer can get at least a 30-fold increase in storage for a given price (for flash memory and hard disk drives) [2] [3] [4]. Iconic glow-up 🤩

High-capacity, low-cost in-network storage opens up a lot of doors 🚪 One example is content caches that support Web and P2P content. DECADE is different from existing content caches, though. Those caches are fully controlled by whoever owns the caching devices. DECADE also lets applications control access to the in-network storage they're allocated, and the resources used while accessing it, like bandwidth, connections, and storage space 👑 Even though DECADE was designed with P2P apps in mind, it could be useful to other apps too 💜 This doc digs into deployed and experimental in-network storage solutions and checks how suitable they are for DECADE.

Quick reality check: the survey here is only representative of the research in this area. It's not an exhaustive list. Instead, it covers some typical techniques that lead to derivative works 🧐

2. Survey Overview 🌷

2.1. Terminology and Concepts 🦋

this doc uses terms defined in [1] 📖

2.2. Historical Context 🕰️

in-network storage has been used in plenty of scenarios to cut network traffic and make content distribution more efficient 💅 This section gives a quick history of content distribution techniques and shows how DECADE connects to past approaches. A lot of systems were built for specific use cases, so this survey isn't trying to call out what existing solutions get wrong. It's more about pointing out where certain capabilities required in DECADE [5] aren't provided by existing systems. No shade, just gaps 🫶

Early on, most Web content lived on a central server, and clients requested it from that one server 🖥️ In that setup, the central server had to provide a lot of bandwidth. As more and more users showed up for Web content, the central server could get overloaded 😭 Web caches are one way to lighten that load. They store frequently requested content and provide bandwidth to serve it to clients 🌸

Broadband keeps growing worldwide, and that's driven by customers hungry for new multimedia services plus Web content 🎬 Audio and video streaming formats in particular have become common for delivering rich info to the public, both residential and business.

To handle all this massive multimedia consumption, just installing more Web caches won't be enough 🙈 Moving content closer to the consumer gives you greater network efficiency, improved Quality of Service (QoS), and lower latency. It also makes it easier to personalize content through broadband content apps 💖 For these edge technologies, Content Delivery Networks (CDNs) are a representative technique. CDNs rely on a large-scale distributed network of servers placed closer to customers so digital content, including many forms of multimedia, gets delivered efficiently ✨

CDNs are a great way to access and deliver information, but there are two barriers to making them a more common service: cost and replication integrity 😤 Deploying a CDN with its infrastructure is expensive. A CDN also needs administrative control over nodes with large storage capacity at geographically dispersed locations that have adequate connectivity. CDNs can scale, but because of that administrative and cost overhead, they aren't rapidly deployable for the common user 🥲

P2P has come a long way and allowed improvements to many network applications 🚀 P2P uses client resources, like CPU, memory, storage, and bandwidth, to serve content. That can reduce the resources a content provider needs. Multimedia delivery using various P2P or peer-assisted frameworks has been shown to greatly reduce dependence on CDNs and central content servers. BUT (plot twist) the popularity of P2P apps has increased traffic on ISP networks 😬 To help, P2P caches, both transparent and non-transparent, have been introduced to reduce that burden. They can be effective at reducing traffic in certain areas of ISP networks, but they have shortcomings. Mainly, they're application-dependent, which makes them hard to keep up to date with new and evolving P2P application protocols. Second, apps may benefit from explicit control of in-network storage, and P2P caches don't give them that. See [1] for more 🧃

So DECADE aims to be a standard protocol that lets P2P applications (including content providers) use in-network storage to lighten the traffic burden on ISP networks. It also lets P2P apps control access to the content they've placed in in-network storage 💅🎀

3. In-Network Storage System Components 🧩

before we survey individual technologies, we break down the basic components of in-network storage 🧠 For consistency and easier comparison, the same model is used to evaluate each storage technology in this document.

Heads up: the network protocol(s) a given storage system uses are also a big part of the design. This doc skips the details of particular protocol choices 🙈

3.1. Data Access Interface 🔑

a set of operations is made available to a user for accessing data in the in-network storage system 📂 Solutions typically allow both read and write operations, though the mechanisms for doing so can differ drastically 🌈

3.2. Data Management Operations 🗂️

okay so storage systems can give users a way to manage their stored stuff 💅 like, delete and move are the kind of things you might get as a user. quick note tho: we're only looking at the data management ops that users get, and we're skipping whatever system admins get 🙈

3.3. Data Search Capability 🔍

some storage systems let you search or enumerate the content they're holding, which is so useful 🧚 again, we're only focusing on search features for users, not admins. example: finding the list of items a certain user stored over a certain stretch of time. literally a whole vibe 🌸

3.4. Access Control Authorization 🔐

storage systems usually let a user, a content owner, or some other entity set the access policies for the in-network storage system. then the system checks whether a user is authorized before it stores or retrieves anything. 👑 we've got three access control types to know: public-unrestricted, public-restricted, and private.

"Public-unrestricted" means the content is wide open to all clients, no restrictions 🌈 think Wikipedia on the Web, or anonymous access to FTP sites. iconic, honestly.

"Public-restricted" is giving selective access 🎀 the content is available to a restricted set of clients (though that set can still be pretty big!), and clients don't need any confidential credentials. example: a TV show episode that can only be watched in certain countries or networks, like white/black lists or black-out areas. the geo-blocking drama is real 💀

"Private" is the most locked-down era 🔒 the content is only available to one or more clients who show the required confidential credentials, like a password or key. no proper credentials, no access. period 💜

Heads up: a combo of access control types can apply to the same scenario! for example, reading content from an in-network storage system could be public-unrestricted, while writing to that same system could be private. two vibes, one system ✨

3.5. Resource Control Interface 🎛️

this is the interface where users manage the resources on in-network storage systems that other peers can use, like bandwidth or connections. the storage system might also let users say how long those resources are granted for 🦋

3.6. Discovery Mechanism 🧭

users rely on the discovery mechanism to find where in-network storage lives, to find an access interface or a resource control interface, or to find other interfaces of in-network storage. finding the right door is everything 🫶

3.7. Storage Mode 🧱

storage systems may use one of these storage modes: file system, object-based, or block-based 💖

a file system usually organizes files into a hierarchical tree 🌳 each level normally has zero or more directories, and each directory has zero or more files. a file system can also be flat or follow some other organizing principle, bestie.

an object-based storage mode stores discrete chunks of data (like IP datagrams or some other aggregation that makes sense to an application) with no pre-defined hierarchy or meta-structure. chunks, no folder drama 🍓

a block-based storage mode stores a raw sequence of bytes, and a client can read and/or write data at offsets within that sequence. data is usually accessed in blocks for efficiency ⚡ the classic example is raw access to a hard disk. very old-school, very iconic 💅

in this survey, "storage mode" means how data is structured inside the system, which might not match how a client accesses it 👀 for example, a caching system might cache objects with hierarchical names, but internally use an object-based storage mode. the outside and inside can be totally different and still slay 🦋

4. In-Network Storage Systems ✨

this section surveys in-network storage systems using the methodology we talked about above 📚 the lineup includes systems that are widely deployed today, systems that are just rolling out, and some experimental ones 🧪 it covers both traditional client-server architectures and P2P architectures 🫶 the surveyed systems are listed in alphabetical order, and for each system there's a quick explanation of how it relates to DECADE 💜

4.1. Amazon S3 ☁️

Amazon S3 (Simple Storage Service) [6] is an online storage service that uses Web (HTTP) interfaces 🌐 users create buckets, and each bucket can hold stored objects. users also get an interface to manage their buckets. Amazon S3 is a super popular backend storage service for other services 👑 other related storage services include the Blob Service from Windows Azure [7], Google Storage for Developers [8], and Dropbox [9]. the storage glow-up is real ✨

4.1.1. Applicability to DECADE 🎯

Amazon S3 is a very widely used (deployed) example of in-network storage 🔥 it leases storage to third-party companies for all kinds of different services. it has a rich authorization model (using signed queries) that fits tons of use cases 🎀 a big focus for Amazon S3 is scalability 📈 some simplifications were made on purpose: there's no general, hierarchical namespace, and you can't update the contents of existing data. no edits, only fresh starts 🙈

4.1.2. Data Access Interface 📥

users can read and write objects 💖

4.1.3. Data Management Operations 🗑️

users can delete previously stored objects 🫧

4.1.4. Data Search Capability 🔎

users can list the contents of buckets to find objects that match what they want 💅

4.1.5. Access Control Authorization 🔐

all access control methods are supported for clients: public-unrestricted, public-restricted, and private 🌈

for example, an owner can restrict access to stored objects, or restrict it to a list of other Amazon S3 Web Service users, or open it up to all Amazon S3 Web Service users. it can also be open to everyone (anonymous access) 🫶 another option is for the owner to generate and sign a query (like a query to read an object) that any user can use until an owner-defined expiration time ⏳ main character access control energy, ngl 👑

4.1.6. Resource Control Interface 🎛️

not provided 🙃

4.1.7. Discovery Mechanism 🧭

users get a well-known DNS name, either a default one from Amazon S3 or one that a particular user customizes 💜 people accessing S3 storage use DNS to discover an IP address where S3 requests can be sent. DNS doing its main-character job 🌸

4.1.8. Storage Mode 🧱

object-based, with the extension that objects can be organized into user-defined buckets 🍓

4.2. BranchCache 🏢

BranchCache [10] is a feature built 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 cut WAN link utilization and boost application responsiveness by caching and sharing content within a branch, all while still keeping end-to-end security 🔒 BranchCache lets files retrieved from Web servers and file servers in headquarters or data centers get cached in remote branch offices, and shared among users in the same branch who access the same content 🎀 it works transparently by instrumenting the HTTP and Server Message Block (SMB) components of the networking stack ✨ there are 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 a local search 🔍 if the content is cached locally, the client retrieves it within the branch. otherwise, the client goes back to the original content server to request the content 🙈 the two modes differ in how the content gets 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 checks the cache for the file it wants first. if it's not 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 on the same network using the Web Services Discovery multicast protocol [11] 📡 just like in the Hosted Cache mode, the client retrieves the file from the content server if it isn't available locally. after retrieving the file (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 so clients can only decrypt the data using keys derived from metadata returned by the content server 🗝️ besides instrumenting the networking stack at clients, content servers must also support BranchCache 🫶

4.2.1. Applicability to DECADE 🎯

BranchCache is an example of an in-network storage system mainly aimed at enterprise networks 🏢 it supports a P2P-like mode (Distributed Cache) as well as a client-server mode (Hosted Cache) 🔄 integration into the Microsoft OS means this in-network storage tech will get wide distribution 🌍 iykyk, and now you do 😭

4.2.2. Data Access Interface 📥

clients transparently retrieve (read) data from a cache (on a client or a Hosted Cache), since BranchCache works by instrumenting the networking stack 🪄 in the Hosted Cache mode, clients write data to the Hosted Cache once it's been retrieved from the content server ✍️

4.2.3. Data Management Operations 🗑️

not provided 🙃

4.2.4. Data Search Capability 🔎

not provided 🙃

4.2.5. Access Control Authorization 🔐

the access control method for clients is private 💜 for example, transferred content is encrypted and can only be decrypted using keys derived from data received from the original content server. data might get transferred to unauthorized clients, but end-to-end security is still maintained because only authorized clients can decrypt it 🛡️ no cap, that's a clever plot twist ✨

4.2.6. Resource Control Interface 🎛️

the storage capacity of caches on clients and Hosted Caches is configurable by system administrators 🧑‍💻 the Hosted Cache also lets you configure the maximum number of simultaneous client accesses 🚦 in the Distributed Cache mode, exponential back-off and throttling mechanisms are used to prevent reply storms of popular content requests 🌊 the client also spreads data-block access across multiple serving clients that have the content (complete or partial), which helps improve latency and gives some load balancing ⚖️ so smart, I'm obsessed 😭

4.2.7. Discovery Mechanism 🧭

the Distributed Cache mode uses multicast to discover other clients and content within a local network 📡 right now, the Hosted Cache mode uses policy provisioning or manual configuration of the server used as the Hosted Cache 🛠️ in this mode, the address of that server may be found via DNS 🌸

4.2.8. Storage Mode 🧱

object-based 🍓

4.3. Cache-and-Forward Architecture 🚀

Cache-and-Forward (CNF) [12] is an architecture for content delivery services for the future Internet 🔮 in this architecture, storage can be used on nodes within the network, either directly on routers or deployed near them 🏗️ CNF is based on the concept of store-and-forward routers with large storage. it provides opportunistic delivery to occasionally disconnected mobile users and 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 like TCP 🧚 hop-by-hop ate, periodt 💅

4.3.1. Applicability to DECADE 💅

Okay so CNF is an experimental in-network storage system, and if it ever got deployed it would need storage space on (or near) a large number of routers across the Internet 🌐 As the name kinda gives away, it's all about short-term caching and NOT long-term network storage. Quick stash, not a forever home 🎀

4.3.2. Data Access Interface 🦋

Users implicitly store content at CNF routers just by requesting files 📥 End hosts read content from in-network storage by sending queries for content. Iconic, no notes 💖

4.3.3. Data Management Operations 🙈

Not provided.

4.3.4. Data Search Capability 🫥

Not provided.

4.3.5. Access Control Authorization 🔐

The access control method is public-restricted, which means it's limited to any client that is part of the CNF network. Only the squad gets in 👑

4.3.6. Resource Control Interface 💤

Not provided.

4.3.7. Discovery Mechanism 🔍

A query that includes a location-independent content ID gets sent to the network and routed to a CNF router. That router handles the retrieval of the data and forwards it to the end host. The way that routing just happens 😭🔥

4.3.8. Storage Mode 🗂️

It's object-based, with objects representing individual files. The architecture proposes to cache large files in storage within the network, though objects could be made to represent smaller chunks of larger files 🍓 Main character flexibility fr

4.4. Cloud Data Management Interface ☁️

The Cloud Data Management Interface (CDMI) is a specification to access and manage cloud storage ✨ CDMI is specified by the Storage Networking Industry Association (SNIA), so it's got serious standards-body energy 🧐

CDMI is a functional interface that applications can use to create, retrieve, update, and delete data elements from the cloud 💅 As part of this interface, the client can discover the capabilities of the cloud storage offering and use the interface to manage containers and the data placed in them. On top of that, metadata can be set on containers and their contained data elements through this interface [13] 📦

CDMI follows a traditional client-server model and operates over an HTTP interface using the Representational State Transfer (REST) model 🌸 Kind of like Amazon S3 buckets (see Section 4.1), users can create containers where data objects get stored. Data objects can be accessed by a user-defined name inside a container, but it's also possible to access them via a storage-defined Object ID, which is handed back in the response when a data object is created 🎀

4.4.1. Applicability to DECADE 🌈

CDMI is a big deal for standardizing storage interfaces for cloud services, which are rapidly becoming a super important type of storage service 🚀 In particular, it specifies a set of operations for creating, reading, writing, and managing data objects at a remote server (or set of servers) via HTTP. Very organized, very slay 👑

4.4.2. Data Access Interface 📖

Users can read and write data objects, and they can also update data in existing data objects ✍️ CDMI data objects are sent on the wire embedded as a field in a JavaScript Object Notation (JSON) object. The protocol also defines interfaces where the contents of data objects can be written via simple HTTP GET/PUT operations 💜

4.4.3. Data Management Operations 🗑️

Users can delete data objects that already exist 💀 The create operation also supports modes where the new object is copied or moved from an existing data object.

Data system metadata also lets users configure policies about time-to-live, after which a data object is automatically deleted, as well as the redundancy with which a data object is stored ⏳

4.4.4. Data Search Capability 🔎

Users may list the contents of containers to locate data objects matching any desired criteria 🧚

4.4.5. Access Control Authorization 🛡️

All methods of access control for clients are supported: public-unrestricted, public-restricted, and private. Every vibe, all of them 🌈

In particular, CDMI lets access to data objects be protected by Access Control Lists (ACLs). These can allow or restrict access based on user name, group, administrative status, or whether a user is authenticated or anonymous 🫶

4.4.6. Resource Control Interface ⚙️

CDMI supports the attributes cdmi_max_latency and cdmi_max_throughput. They can be set at the level of containers or at a specific data object, and they control the level of service offered to any users accessing a particular data object 🔥

4.4.7. Discovery Mechanism 📡

Users are provided a well-known DNS name. That DNS name gets resolved to determine the IP address that requests may be sent to 🧭

4.4.8. Storage Mode 🗃️

It's object-based, with the extension that objects can be organized into user-defined containers 📁 Very neat and organized, bestie 🎀

4.5. Content Delivery Network 🚚

A CDN provides services that improve performance by minimizing the amount of data transmitted through the network, improving accessibility, and maintaining correctness through content replication 💖 CDNs offer fast and reliable applications and services by distributing content to cache or edge servers located close to users. See [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 is 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, and it also works 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 makes sure content stays consistent in the caches 🔄 The accounting infrastructure keeps logs of client accesses and records the usage of the CDN servers. That info 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 big focus for CDNs is being able to publish and deliver content to end users in a reliable and timely manner ⏰ A CDN builds 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. That's a whole list, honestly 😭

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 🫶

4.5.1. Applicability to DECADE 🌍

CDNs are a very widely used (deployed) example of in-network storage for multimedia content 🎬 The existence and operation of the storage system are totally transparent to the end user, so nobody even notices 🙈 CDNs typically require a strong business relationship between content providers and content distributors, and that relationship often extends to the ISPs 🤝

4.5.2. Data Access Interface 👀

A CDN is typically a closed system, and it generally provides only a read (retrieve) access interface to clients. It typically does not provide a write (store) access interface to clients 🚫 The content provider can access network edge servers and store content on them, or edge servers can retrieve content from content providers. Client nodes can only retrieve content from edge servers 📥

4.5.3. Data Management Operations 🧹

A content provider can manage the data distributed across different cache nodes, like moving popular data objects from one cache node to another, or deleting rarely accessed data objects in cache nodes. User nodes, however, have no right to perform these operations 🙅‍♀️

4.5.4. Data Search Capability 🔭

A content provider can search or enumerate the data each cache node stores. User nodes cannot perform search operations 🚷

4.5.5. Access Control Authorization 🔑

All methods of access control (for reading) are supported for clients: public-unrestricted, public-restricted, and private. Some CDN edge servers allow HTTP basic authentication with the origin server, or restrictions by IP address. They can also use a token-based technique so the origin server can apply its own authorization criteria 🪪

As mentioned previously, clients typically cannot write to the CDN. Writing is typically a private operation for the content providers 💅

4.5.6. Resource Control Interface 💤

Not provided.

4.5.7. Discovery Mechanism 🧭

Content providers can directly find internal CDN cache nodes to store content, since they typically have an explicit business relationship 🤝 Clients can locate CDN nodes through DNS or other redirection mechanisms 🌐

4.5.8. Storage Mode 🧱

Even though objects are addressed using URLs that typically refer to them in a hierarchical fashion, the storage mode is typically object-based 🎀

4.6. Delay-Tolerant Network 🛰️

The Delay-Tolerant Network (DTN) [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 used in various operational environments characterized by severe communication disruptions, disconnections, and high delays. For example, there could be a month-long loss of connectivity between two planetary networks because of high solar radiation due to sun spots ☀️ The DTN architecture is therefore 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 [16] 🧁 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. Traditional IP networks are also based on store-and-forward principles, but the amount of time a packet is 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 💾

4.6.1. Applicability to DECADE 🌌

The DTN is an example of an experimental in-network storage system that would require fundamental changes to the Internet protocols 🧪

4.6.2. Data Access Interface 📨

Users implicitly cause content to be stored (until successfully forwarded) at Bundle Layer nodes by initiating or terminating any transaction that traverses the DTN 🫧

4.6.3. Data Management Operations ⏱️

Users can implicitly cause deletion of content stored at Bundle Layer nodes via a "time-to-live" type of parameter that the user can control (for transactions originating from the user) 💫

4.6.4. Data Search Capability 🙅

Not provided.

4.6.5. Access Control Authorization 🔐

The access control method is public-restricted (to any client that is part of the DTN) or private 👑

4.6.6. Resource Control Interface 💤

Not provided.

4.6.7. Discovery Mechanism 🔗

A Uniform Resource Identifier (URI) approach is used as the basis of the addressing scheme for DTN transactions, and for the subsequent store-and-forward routing through the DTN network 🦋

4.6.8. Storage Mode ✨

Object-based. DTN applications send data to the Bundle Layer, which then breaks the data into segments. These segments are then routed through the DTN network, and stored in Bundle Layer nodes as required (before being forwarded). 🧚

4.7. Named Data Networking 🌸

Named Data Networking (NDN) [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. okay this is so cool 😭

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 [18]. the reverse path thing is giving main character energy 💜

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. 🦋

4.7.1. Applicability to DECADE 🎀

NDN is an example of an experimental in-network storage system that would require storage space on a large number of routers in the Internet. Named Data packets would be kept in storage in the NDN routers and provided to new requesters of the same data.

4.7.2. Data Access Interface 💅

Users implicitly store content at NDN routers by requesting content (the named Data packets) from the network. Subsequent requests by different users for the same content will cause the named Data packets to be read from the NDN routers' in-network storage.

4.7.3. Data Management Operations 🙈

Users do not have the direct ability to delete content stored in the NDN routers. However, there will be some type of time-to-live parameter associated with the named Data packets, though this has not yet been specified. ngl that's a little bit of a cliffhanger 💀

4.7.4. Data Search Capability 🍓

Not provided.

4.7.5. Access Control Authorization 🔥

All methods of access control for clients are supported: public-unrestricted, public-restricted, and private.

The basic security mechanism in NDN is for the sender to digitally sign the content (the named Data packets) that it sends. It is envisioned that a complete access control system can be built on top of NDN, though this has not yet been specified.

4.7.6. Resource Control Interface 🌈

Not provided.

4.7.7. Discovery Mechanism 🧚

Names are used as the basis of the addressing and discovery scheme for NDN (and subsequent store-and-forward routing through the NDN network). NDN names are assumed to be hierarchical and to be able to be deterministically constructed. This is still an active area of research.

4.7.8. Storage Mode 🫶

Object-based. NDN sends named Data packets through the network. These Data packets are routed through the NDN network and stored in NDN routers.

4.8. Network of Information 🦋

Similar to NDN (see Section 4.7), Network of Information (NetInf) [19] 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. the trust-the-info-not-the-infrastructure vibe is so iconic ✨

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. 🍓

4.8.1. Applicability to DECADE 🎀

NetInf is an example of an experimental information-centric network architecture that will require storage space for storage and caching of information objects on a large number of NetInf nodes in the Internet.

4.8.2. Data Access Interface 💅

Users will publish IOs with specific IDs into the network. This is done by the client sending a register message to the NRS stating that the IO with the specific ID is available. When another user wishes to retrieve the IO, they will use the given ID to make a request for the IO. The ID is then resolved by the NRS, and the IO is delivered from a nearby in-network storage location.

4.8.3. Data Management Operations 🙈

Users do not have the direct ability to delete content stored in the NetInf nodes. However, there can be some type of time-to-live parameter associated with the information objects, though this has not yet been specified.

4.8.4. Data Search Capability 🍓

Not provided.

4.8.5. Access Control Authorization 🔥

All methods of access control for clients are supported: public-unrestricted, public-restricted, and private. The basic security mechanism in NetInf is for the publisher to digitally sign the content of the information object that it publishes. It is envisioned that a complete access control system can be built on top of NetInf, though this has not yet been specified.

4.8.6. Resource Control Interface 🌈

Not provided.

4.8.7. Discovery Mechanism 🧚

NetInf IDs are used for naming and accessing information objects. The IDs are resolved by the NRS into locators that are used for routing and transport of data through the transport networks. This is still an active area of research.

4.8.8. Storage Mode 🫶

Object-based. From an application perspective, NetInf can be used for publishing entire files or chunks of files. NetInf is agnostic to the application perspective and treats everything as information objects.

4.9. Network Traffic Redundancy Elimination 💖

Redundancy Elimination (RE) is used for identifying and removing repeated content from network transfers. This technique has been proposed to improve network performance in many types of networks, such as ISP backbones and enterprise access links. One example of an RE proposal is SmartRE [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. 🧠

4.9.1. Applicability to DECADE 🎀

RE is an example of an experimental in-network storage system that would require a large amount of associated packet processing at routers if it was ever deployed.

4.9.2. Data Access Interface 💅

RE is typically transparent to the user. Writing into storage is done by transferring data that has not already been cached. Storage is read when users transmit data identical to previously transmitted data.

4.9.3. Data Management Operations 🙈

Not provided.

4.9.4. Data Search Capability 🍓

Not provided.

4.9.5. Access Control Authorization 🔥

The access control method is public-restricted (to any client that is part of the RE network). Note that the content provider still retains control over which peers receive the requested data. The returned data is "compressed" as it is transferred within the network.

4.9.6. Resource Control Interface 🌈

Not provided. The content provider still retains control over the rate at which packets are sent to a peer. The packet size within the network may be reduced.

4.9.7. Discovery Mechanism 🧚

No discovery mechanism is necessary. Routers can use RE without the users' knowledge.

4.9.8. Storage Mode 🫶

Object-based, with "objects" being data from packets transmitted within the network.

4.10. OceanStore 🌊

OceanStore [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. the "some nodes are compromised and it still works" energy is so strong 👑

4.10.1. Applicability to DECADE 🎀

OceanStore is an example of an experimental in-network storage system that provides a high degree of network resilience to failure scenarios.

4.10.2. Data Access Interface 💅

Users may read and write objects.

4.10.3. Data Management Operations 🙈

Objects may be replaced by newer versions, and multiple versions of an object may be maintained.

4.10.4. Data Search Capability 🍓

Not provided.

4.10.5. Access Control Authorization 🔥

Provided, but specifics for clients are unclear from the available references.

4.10.6. Resource Control Interface 🌈

Not provided.

4.10.7. Discovery Mechanism 🧚

Users require an entry point into the system in the form of one storage node that is part of OceanStore. If a hostname is provided, the address of a storage node may be determined via DNS.

4.10.8. Storage Mode 🫶

Object-based.

4.11. P2P Cache 💖

Okay bestie, caching P2P traffic is lowkey genius 🧚 because P2P objects are mostly immutable (they don't change once they exist) and the traffic is super repetitive. So caching cuts down on P2P network traffic. The best part? Making use of P2P caches doesn't require any changes to P2P protocols, and it can be deployed transparently from clients. No cap ✨

P2P caches work kinda like Web caches (Section 4.14) because they both temporarily store frequently requested content. If the content is already in the cache, the request gets served from local storage instead of sending the data over expensive network links 💸

There are two types of P2P caches: transparent P2P caches and non-transparent P2P caches 🦋

For a transparent cache, once a P2P cache is established, the network transparently redirects P2P traffic to the cache. The cache either serves the file directly or passes the request on to a remote P2P user and caches that data at the same time. 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 are therefore supported by caches, which leads to higher complexity. Plus, these protocols evolve over time, and new protocols keep getting introduced 💀

4.11.1. Applicability to DECADE

A P2P cache is an example of in-network storage for P2P systems. However, unlike DECADE, the existence and operation of the storage system are totally transparent to the end user 🎀

4.11.2. Transparent P2P Caches

4.11.2.1. Data Access Interface

The data access interface allows P2P content to be cached (stored) and supplied (retrieved) locally, so network traffic is reduced. It's transparent to P2P users, and P2P users implicitly use the data access interface (in the form of their native P2P application protocol) to store or retrieve content 🫶

4.11.2.2. Data Management Operations

Not provided.

4.11.2.3. Data Search Capability

Not provided.

4.11.2.4. Access Control Authorization

The access control method is typically public-restricted (to any client that is part of the P2P channel or swarm) 🔒

4.11.2.5. Resource Control Interface

Not provided.

4.11.2.6. Discovery Mechanism

The use of DPI means that no discovery mechanism is provided to P2P users, since it's transparent to them. Because DPI is used to recognize P2P applications' private protocols, P2P cache implementations must be updated as new applications are added and existing protocols evolve 🙈

4.11.2.7. Storage Mode

Object-based. Chunks (typically, the unit of transfer among P2P clients) of content are stored in the cache 🍓

4.11.3. Non-Transparent P2P Caches

4.11.3.1. Data Access Interface

The data access interface allows P2P content to be cached (stored) and supplied (retrieved) locally, so network traffic is reduced. P2P users implicitly store and retrieve from the cache using the P2P application's native protocol 💖

4.11.3.2. Data Management Operations

Not provided.

4.11.3.3. Data Search Capability

Not provided.

4.11.3.4. Access Control Authorization

The access control method is typically public-restricted (to any client that is part of the P2P channel or swarm) 🔒

4.11.3.5. Resource Control Interface

Not provided.

4.11.3.6. Discovery Mechanism

A P2P cache node behaves as if it were a normal peer in order to join the P2P overlay network. Other P2P users can find such a cache node through an overlay routing mechanism and can interact with it as if it were a normal neighbor node 🧚

4.11.3.7. Storage Mode

Object-based. Chunks (typically, the unit of transfer among P2P clients) of content are stored in the cache 🍓

There are a growing number of popular online photo-sharing (storing) systems. For example, the Kodak Gallery system [22] serves over 60 million users and stores billions of images [23]. Other well-known examples of photo-sharing systems include Flickr [24] and ImageShack [25]. There are also a number of popular blogging services, such as Tumblr [26], 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 🌸

4.12.1. Applicability to DECADE

Photo sharing is a very widely used (deployed) example of in-network storage where the end user has direct visibility and extensive control of the system. The typical end-user interface is through an HTTP-based Web browser 🦋

4.12.2. Data Access Interface

Users can read (view) and write (store) photos 📷

4.12.3. Data Management Operations

Users can delete previously stored photos 🗑️

4.12.4. Data Search Capability

Users can tag photos and/or organize them using sophisticated Web photo album generators. Users can then search for objects (photos) matching desired criteria 🔍

4.12.5. Access Control Authorization

The access control method for clients is typically either private or public-unrestricted. For example, writing (storing) to a photo blog is typically private to the owner of the account. However, all other clients can view (read) the contents of the blog (i.e., public-unrestricted). Some photo-sharing Websites provide private access to read photos, which allows sharing with a limited set of friends 💜

4.12.6. Resource Control Interface

Not provided.

4.12.7. Discovery Mechanism

Clients usually log on manually to a central Web page for the service and enter the appropriate information to access the desired information. The address the client connects to is usually determined by DNS, using the hostname from the provided URL 🌈

4.12.8. Storage Mode

File system (file-based). Photos are usually stored as files. They can then be organized into meta-structures (e.g., albums, galleries, etc.) using sophisticated Web photo album generators 🎀

4.13. Usenet 🗞️

Usenet is a distributed Internet-based discussion (message) system. The Usenet messages are arranged as a set of "newsgroups" that are classified hierarchically by subject. Usenet information is distributed and stored among a large conglomeration of servers that store and forward messages to one another in so-called news feeds. Individual users may read messages from, and post messages to, a local news server, typically operated by an ISP. This local server communicates with other servers and exchanges articles with them. In this fashion, the message is copied from server to server and eventually reaches every server in the network [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 [28] 🌸

4.13.1. Applicability to DECADE

Usenet is a historically very important and widely used (deployed) example of in-network storage in the Internet. The use of this system is rapidly declining, but efforts have been made to preserve the stored content for historical purposes 📜

4.13.2. Data Access Interface

Users can read and post (store) messages 💌

4.13.3. Data Management Operations

Users sometimes have limited ability to delete messages that they previously posted 😭

4.13.4. Data Search Capability

Traditionally, users could manually search through the newsgroups, as they are classified hierarchically by subject. In the newer Web-based systems, there is also an automatic search capability based on key-word matches 🔍

4.13.5. Access Control Authorization

The access control method is either public-unrestricted or private (to client members of that newsgroup) 🔐

4.13.6. Resource Control Interface

Not provided.

4.13.7. Discovery Mechanism

Clients usually log on manually to their Usenet accounts. DNS may be used to resolve hostnames to their corresponding addresses 🫶

4.13.8. Storage Mode

File system. Messages are usually stored as files that are then organized hierarchically by subject into newsgroups 🗂️

4.14. Web Cache 🌐

Web cache [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 it 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) [30]. It proposes sharing chunks of P2P files/streams using HTTP with cache-control headers 🦋

4.14.1. Applicability to DECADE

Web cache is a very widely used (deployed) example of in-network storage for the key Internet application of Web browsing. The existence and operation of the storage system are transparent to the end user in most cases. The content caching time is controlled by time-to-live parameters associated with the original content. The principle of Web caching is to speed up Web page reading by using (the same) content previously requested by another user to service a new user 🚀

4.14.2. Data Access Interface

Users explicitly read from a Web cache by making requests, but they cannot explicitly write data into it. Data is implicitly stored in the Web cache by requesting content that is not already cached and meets policy restrictions of the cache provider 🌸

4.14.3. Data Management Operations

Not provided.

4.14.4. Data Search Capability

Not provided.

4.14.5. Access Control Authorization

The access control method for clients is public-unrestricted. It is important to note that if content is authenticated or encrypted (e.g., HTTPS, Secure Socket Layer (SSL)), it will not be cached. Also, if the content is flagged as private (vs. public) at the HTTP level by the origin server, it will not be cached 🔒

4.14.6. Resource Control Interface

Not provided.

4.14.7. Discovery Mechanism

Web caches can be transparently deployed between a Web server and Web clients, employing DPI for discovery. Alternatively, Web caches could be explicitly discovered by clients using techniques such as DNS or manual configuration 🧚

4.14.8. Storage Mode

Object-based. Web content is keyed within the cache by HTTP Request fields, such as Method, URI, and Headers 🍓

4.15. Observations Regarding In-Network Storage Systems 🫶

Okay bestie, here's the tea on the in-network storage systems we surveyed, all in the DECADE context from [1] 💅

Most of the surveyed systems were built for client-server architectures, so they don't do P2P 💀 BUT there are some major exceptions, especially newer stuff like BranchCache and P2P cache, which do have a P2P mode of operation ✨

P2P cache systems are lowkey iconic because they don't need any changes to the P2P apps themselves 🦋 The catch is that they have to support each application protocol, so it's not all sunshine 🌸

A bunch of the surveyed systems were made for caching rather than long-term network storage 🧚 So during DECADE protocol design, it's worth really thinking about whether a caching mode should be supported in addition to a long-term network storage mode. There's usually a trade-off between caching and long-term (and usually also reliable) storage when it comes to some performance metrics 📊 Also, [1] points out problems with classical caching from a DECADE perspective, like how P2P caches typically don't let users explicitly control what gets stored in the cache 🙈

Some parts of the surveyed systems are outside DECADE's scope 💜 For example, a protocol for searching across multiple DECADE servers is out of scope. Applications may still be able to build that kind of thing if DECADE exposes the right primitives 🎀 This is honestly the best part: it keeps the core in-network storage systems simple while letting diverse apps design their own mechanisms for their own needs 👑

Right now, most in-network storage systems follow some version of the authorization model of public-unrestricted, public-restricted, and private 🔐 For DECADE, we may need to evolve the authorization model to support resource owner (e.g., end user) authorization, in addition to network authorization. Plot twist, the owner matters too 😭

This section surveys existing storage and other related protocols, and comments on how they could be used to meet DECADE's use cases. The surveyed protocols are listed alphabetically 📚

5.1. HTTP 🌐

HTTP [31] is a key protocol for the World Wide Web 💖 It's a stateless client-server protocol that lets applications be designed using the REST model. HTTP is often associated with downloading (reading) content from Web servers to Web browsers, but it also supports uploading (writing) content to Web servers. It has also 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 we looked at earlier, including CDNs, photo sharing, and Web cache 📸 Using HTTP for a storage protocol means no extra software is required on the client (i.e., a Web-based client), since all standard Web browsers are based on HTTP. Iconic, honestly 🫶

5.1.1. Data Access Interface

Basic read and write operations are supported (using HTTP GET, PUT, and POST methods) 📖

5.1.2. Data Management Operations

Not provided 🙅‍♀️

5.1.3. Data Search Capability

Not provided 🙅‍♀️

5.1.4. Access Control Authorization

All methods of access control for clients are supported: public-unrestricted, public-restricted, and private 🔑

Most Web pages are public-unrestricted when it comes to reading, but they don't allow any uploading of content. In-network storage systems range from private or public-unrestricted for photo sharing (described in Section 4.12.5) to public-unrestricted for Web caching (described in Section 4.14.5) 📸🌸

5.1.5. Resource Control Interface

Not provided 🙅‍♀️

5.1.6. Discovery Mechanism

Manual configuration is typically used. Clients typically address HTTP servers by providing a hostname, which gets resolved to an address using DNS 🗺️

5.1.7. Storage Mode

HTTP is a protocol, so it doesn't define a storage mode. However, a non-collection resource can typically be thought of as a "file" 🗂️ These files may be organized into collections, which typically map onto the HTTP path hierarchy, creating the illusion of a file system ✨

5.1.8. Comments

HTTP is based on a client-server architecture, so it isn't directly applicable to DECADE's P2P focus 😭 Also, HTTP offers only a rudimentary toolset for storage operations compared to some of the other storage protocols 💀

5.2. iSCSI 💾

Small Computer System Interface (SCSI) is a set of protocols for communicating with storage devices like disk drives and tapes. Internet SCSI (iSCSI) [32] is a protocol that lets SCSI commands be sent over TCP 🧠 Just like in SCSI, iSCSI lets an Initiator send commands to a Target. These commands operate at the device level, rather than on individual data objects stored on the device 🎀

5.2.1. Data Access Interface

Read and write commands indicate which data is to be read or written by specifying the offset (using Logical Block Addressing) into the storage device. The size of the data to be read or written is an additional parameter in the command 📏

5.2.2. Data Management Operations

Since commands operate at the device level, management operations are different from traditional file systems. Management commands for SCSI/iSCSI include explicit device control commands, such as starting, stopping, and formatting the device 🔧

5.2.3. Data Search Capability

SCSI/iSCSI doesn't provide a way to search for particular data within a device. Note that such capabilities can be implemented outside of iSCSI 🔍

5.2.4. Access Control Authorization

When it comes to access to devices, the access control method is private 🔒 iSCSI uses the Challenge Handshake Authentication Protocol (CHAP) [33] to authenticate Initiators and Targets when they access 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 🫠

5.2.5. Resource Control Interface

Not provided 🙅‍♀️

5.2.6. Discovery Mechanism

Manual configuration may be used. An alternative is the Internet Storage Name Service (iSNS) [34], which provides the ability to discover available storage resources 🔎

5.2.7. Storage Mode

As a protocol, iSCSI doesn't explicitly have a storage mode. However, it provides block-based access to clients. SCSI/iSCSI gives an Initiator block-level access to the storage device 🧱

5.3. NFS 📁

The Network File System (NFS) is designed to let users access files over a network, similar to how local storage is accessed 🖥️ NFS is typically used in local area networks or in enterprise settings, though changes made in later versions of NFS (e.g., [35]) make it easier to operate over the Internet 🌍

5.3.1. Data Access Interface

Traditional file-system operations like read, write, and update (overwrite) are provided. Locking is provided to support concurrent access by multiple clients 🔐

5.3.2. Data Management Operations

Traditional file-system operations like move and delete are provided 🗑️

5.3.3. Data Search Capability

The user can list the contents of directories to find filenames that match the desired criteria 🕵️‍♀️

5.3.4. Access Control Authorization

All methods of access control for clients are supported: public-unrestricted, public-restricted, and private 🛡️ For example, files and directories can be protected using read, write, and execute permissions for the files' owner and group, and for the public (others). NFSv4.1 also has a rich ACL model that allows a list of Access Control Entries (ACEs) to be configured for each file or directory 💅 The ACEs can specify per-user read/write access to file data, file/directory attributes, creation/deletion of files in a directory, and so on 👑

5.3.5. Resource Control Interface

While disk space quotas can be configured, administrative policy typically limits the total amount of storage allocated to a particular user. User control of bandwidth and connections used by remote peers isn't provided 🚫

5.3.6. Discovery Mechanism

Manual configuration is typically used. Clients address NFS servers by providing a hostname and a directory that should be mounted. DNS may be used to look up an address for the provided hostname 🧭

5.3.7. Storage Mode

As a protocol, there's no defined internal storage mode. However, implementations typically use the underlying file-system storage. Extensions have been defined for alternate storage modes (e.g., block-based [36] and object-based [37]) 🧩

5.3.8. Comments

The efficiency and scalability of the NFS access control method are concerns in the context of DECADE 😬 In particular, Section 6.2.1 of [35] states that:

   Only ACEs that have a "who" that matches the requester
   are considered.

So 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. The concern with this approach is scalability, especially when a client's peers 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 🔗

5.4. OAuth 🪪

Open Authorization (OAuth) [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", which lets a resource owner authorize a particular client for access (e.g., for a particular lifetime) to private resources 🎟️

We include OAuth in this survey so its authentication model can be evaluated in the context of DECADE. OAuth itself, however, is not a network storage protocol 🙈

5.4.1. Data Access Interface

Not provided 🙅‍♀️

5.4.2. Data Management Operations

Not provided 🙅‍♀️

5.4.3. Data Search Capability

Not provided 🙅‍♀️

5.4.4. Access Control Authorization

Not provided. While similar in spirit to the WebDAV ticketing extensions [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 the resource owner can also revoke them at any time ⏳

5.4.5. Resource Control Interface

Not provided 🙅‍♀️

5.4.6. Discovery Mechanism

Not provided 🙅‍♀️

5.4.7. Storage Mode

Not provided 🙅‍♀️

5.4.8. Comments

The ticketing mechanism requires server involvement, and the discussion about WebDAV's proposed ticketing mechanism (see Section 5.5.8) applies here as well 🎀

5.5. WebDAV 🎀

okay so WebDAV is [40], and it's basically a protocol built for Web content authoring 💅. It's developed as an extension to HTTP (see Section 5.1), which makes it way simpler to slot into software that already speaks HTTP 🦋. It supports the classic read/write-from-storage stuff, plus extra constructs like locking and collections that matter a LOT when multiple people are collaborating to author or edit a set of documents 💖.

5.5.1. Data Access Interface ✨

Reading and writing are supported the usual way, using HTTP GET and PUT methods 📖. Locking is also provided so multiple clients can access the same stuff at the same time without chaos 🔒.

5.5.2. Data Management Operations 🌸

WebDAV handles traditional file-system operations like move, delete, and copy 🧚. Objects get organized into collections, and those operations work on collections too 🗂️. WebDAV also lets objects have user-defined properties, which is so iconic 👑.

5.5.3. Data Search Capability 🔍

The user can list the contents of collections to hunt down objects that match what they want 🕵️‍♀️. There's also a SEARCH extension [41] that's been specified, which lets you list objects matching criteria that the client defines itself 💜.

5.5.4. Access Control Authorization 🔐

All the access control methods for clients are supported here: public-unrestricted, public-restricted, and private 🫶.

Also, there's an ACL extension [42] for WebDAV 🎀. ACLs let you set up both user-based and group-based access control policies (covering reading, writing, properties, locking, and so on) for objects and collections 💅.

There's a ticketing extension [39] that's been proposed, but honestly it hasn't moved since 2001 😭. It lets a client ask the WebDAV server to create a "ticket" (for reading an object, for example) that can then be handed out to other clients 🎟️. Tickets can have expiration times, or they can only allow a fixed number of uses 🍓. The proposed extension says the server has to generate tickets and keep track of state for outstanding tickets 🙈.

5.5.5. Resource Control Interface 🌈

An extension [43] lets you configure disk space quotas for collections ⭐. It also lets WebDAV clients check how much disk space is currently in use 📊. User control over the bandwidth and connections used by remote peers is not provided 💀.

5.5.6. Discovery Mechanism 🧭

Manual configuration is what's typically used 🛠️. Clients address WebDAV servers by providing a hostname, which can be resolved to an address using DNS 🌐.

5.5.7. Storage Mode 💾

No storage mode is explicitly defined, but WebDAV can be thought of as giving a client file system (file-based) storage 📁. A non-collection resource can typically be thought of as a "file" 📄. Files may be organized into collections, which typically map onto the HTTP path hierarchy 🌳.

5.5.8. Comments 💭

The efficiency and scalability of the WebDAV access control method are concerns in the context of DECADE 😬, for reasons similar to those stated in 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 ⏳.

The following observations about the surveyed storage and related protocols are made in the context of DECADE as defined by [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 🥳.

6. Conclusions 🎉

Though there have been many successful in-network storage systems, they have been designed for use cases different from those defined in DECADE 🤷‍♀️. For example, many of the surveyed in-network storage systems and protocols were designed for client-server architectures and not P2P 🖥️. No surveyed system or protocol has the functionality and features to fully meet the set of requirements defined for DECADE 😮‍💨. DECADE aims to provide a standard protocol for P2P applications and content providers to access and control in-network storage, resulting in increased network efficiency while retaining control over content shared with peers 🦋. Additionally, defining a standard protocol can reduce the complexity of in-network storage, since multiple P2P application protocols no longer need to be implemented by in-network storage systems 🧹.

7. Security Considerations 🚨

This document is a survey of existing in-network storage systems, and does not introduce any security considerations beyond those of the surveyed systems 🔐.

For more information on security considerations of DECADE, see [1] 📚.

8. Contributors 🫶

The editors would like to thank the following people for contributing to the development of this document 💜:

ZhiHui Lv 🌟
Borje Ohlman 🌟
Pang Tao 🌟
Lucy Yong 🌟
Juan Carlos Zuniga 🌟

9. Acknowledgments 🌈

The editors would like to thank the following people for providing valuable comments to various draft versions of this document: David Bryan, Tao Mao, Haibin Song, Ove Strandberg, Yu-Shun Wang, Richard Woundy, Yunfei Zhang, and Ning Zong 💖✨.

10. Informative References 🧾✨

okay bestie, here are the receipts 💅 every source this spec pulls from, with all the details so you can go find them yourself 🔍

[1] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", Work in Progress, October 2011.

[2] Storage Search, "Flash Memory vs. Hard Disk Drives -- Which Will Win?", <http://www.storagesearch.com/semico-art1.html>.

[3] Brisken, W., "Hard Drive Price Trends", US VLBI Technical Meeting, May 2008.

[4] 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>.

[5] Gu, Y., Bryan, D., Yang, Y., and R. Alimi, "DECADE Requirements", Work in Progress, September 2011.

[6] Amazon Web Services, "Amazon Simple Storage Service (Amazon S3)", <http://aws.amazon.com/s3/>.

[7] Calder, B., Wang, T., Mainali, S., and J. Wu, "Windows Azure Blob -- Programming Blob Storage", May 2009, <http://www.microsoft.com/windowsazure/whitepapers/>.

[8] Google, "Google Storage for Developers", <http://code.google.com/apis/storage>.

[9] Dropbox, "Dropbox Features", <http://www.dropbox.com/features>.

[10] Microsoft Corporation, "BranchCache", <http://technet.microsoft.com/en-us/network/dd425028.aspx>.

[11] Microsoft Corporation, "Web Services Dynamic Discovery (WS-Discovery)", April 2005, <http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf>.

[12] 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.

[13] SNIA, "Cloud Data Management Interface (CDMI)", <http://www.snia.org/cdmi>.

[14] 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.

[15] 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.

[16] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.

[17] Named Data Networking, "Named Data Networking Home Page", <http://www.named-data.net/>.

[18] Named Data Networking, "Named Data Networking (NDN) Project", <http://www.named-data.net/ndn-proj.pdf>.

[19] Network of Information, "NetInf Overview", <http://www.netinf.org/home/overview/>.

[20] Anand, A., Sekar, V., and A. Akella, "SmartRE: An Architecture for Coordinated Network-wide Redundancy Elimination", SIGCOMM 2009.

[21] Rhea, S., Eaton, P., Geels, D., Weatherspoon, H., Zhao, B., and J. Kubiatowicz, "Pond: the OceanStore Prototype", FAST 2003.

[22] Kodak, "Kodak Gallery Home Page", <http://www.kodakgallery.com/gallery/welcome.jsp>.

[23] Wikipedia, "Kodak Gallery", <http://en.wikipedia.org/wiki/Kodak_Gallery>.

[24] Flickr, "Flickr Home Page", <http://www.flickr.com>.

[25] ImageShack, "ImageShack Home Page", <http://imageshack.us>.

[26] Tumblr, "Tumblr Home Page", <http://www.tumblr.com>.

[27] Wikipedia, "Usenet", <http://en.wikipedia.org/wiki/Usenet>.

[28] Google, "Google Groups", <http://groups.google.com>.

[29] Huston, G., Telstra, "Web Caching", The Internet Protocol Journal Volume 2, No. 3.

[30] 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).

[31] 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.

[32] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.

[33] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

[34] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.

[35] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.

[36] Black, D., Fridella, S., and J. Glasgow, "Parallel NFS (pNFS) Block/Volume Layout", RFC 5663, January 2010.

[37] Halevy, B., Welch, B., and J. Zelenka, "Object-Based Parallel NFS (pNFS) Operations", RFC 5664, January 2010.

[38] Hammer-Lahav, E., Ed., "The OAuth 1.0 Protocol", RFC 5849, April 2010.

[39] Ito, K., "Ticket-Based Access Control Extension to WebDAV", Work in Progress, October 2001.

[40] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.

[41] Reschke, J., Ed., Reddy, S., Davis, J., and A. Babich, "Web Distributed Authoring and Versioning (WebDAV) SEARCH", RFC 5323, November 2008.

[42] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004.

[43] Korver, B. and L. Dusseault, "Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections", RFC 4331, February 2006.

Authors' Addresses 🎀

Richard Alimi (editor) 💖 Google

EMail: ralimi@google.com

Akbar Rahman (editor) 🦋 InterDigital Communications, LLC

EMail: Akbar.Rahman@InterDigital.com

Yang Richard Yang (editor) 🌸 Yale University

EMail: yry@cs.yale.edu

and that's a wrap on RFC 6392, bestie!! 🌈👑 you made it through the whole thing 😭🫶

📦 where this page comes from

ietf: rfc6392 2011-10
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms