idnits 2.17.1 draft-ietf-decade-arch-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2012) is 4295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) == Outdated reference: A later version (-08) exists of draft-ietf-decade-reqs-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DECADE R. Alimi 3 Internet-Draft Google 4 Intended status: Informational A. Rahman 5 Expires: January 14, 2013 InterDigital Communications, LLC 6 D. Kutscher 7 NEC 8 Y. Yang 9 Yale University 10 July 13, 2012 12 DECADE Architecture 13 draft-ietf-decade-arch-08 15 Abstract 17 Content Distribution Applications (e.g., P2P applications) are widely 18 used on the Internet and make up a large portion of the traffic in 19 many networks. One technique to improve the network efficiency of 20 these applications is to introduce storage capabilities within the 21 networks; this is the capability provided by a DECADE (DECoupled 22 Application Data Enroute) compatible system. This document presents 23 an architecture, discusses the underlying principles, and identifies 24 key functionalities in the architecture for introducing a DECADE- 25 compatible in-network storage system. In addition, some examples are 26 given to illustrate these concepts. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 14, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Architectural Principles . . . . . . . . . . . . . . . . . . . 6 73 4.1. Decoupled Control/Metadata and Data Planes . . . . . . . . 6 74 4.2. Immutable Data Objects . . . . . . . . . . . . . . . . . . 7 75 4.3. Data Objects With Identifiers . . . . . . . . . . . . . . 8 76 4.4. Explicit Control . . . . . . . . . . . . . . . . . . . . . 10 77 4.5. Resource and Data Access Control through Delegation . . . 10 78 5. System Components . . . . . . . . . . . . . . . . . . . . . . 11 79 5.1. Content Distribution Application . . . . . . . . . . . . . 11 80 5.2. DECADE Server . . . . . . . . . . . . . . . . . . . . . . 13 81 5.3. Data Sequencing and Naming . . . . . . . . . . . . . . . . 15 82 5.4. Token-based Authorization and Resource Control . . . . . . 17 83 5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 18 84 6. DECADE Protocols . . . . . . . . . . . . . . . . . . . . . . . 19 85 6.1. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 19 86 6.2. Standard Data Transfer (SDT) Protocol . . . . . . . . . . 22 87 6.3. Server-to-Server Protocols . . . . . . . . . . . . . . . . 23 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 89 7.1. Threat: System Denial of Service Attacks . . . . . . . . . 25 90 7.2. Threat: Protocol Security . . . . . . . . . . . . . . . . 25 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 96 Appendix A. In-Network Storage Components Mapped to DECADE 97 Architecture . . . . . . . . . . . . . . . . . . . . 28 98 A.1. Data Access Interface . . . . . . . . . . . . . . . . . . 28 99 A.2. Data Management Operations . . . . . . . . . . . . . . . . 29 100 A.3. Data Search Capability . . . . . . . . . . . . . . . . . . 29 101 A.4. Access Control Authorization . . . . . . . . . . . . . . . 29 102 A.5. Resource Control Interface . . . . . . . . . . . . . . . . 29 103 A.6. Discovery Mechanism . . . . . . . . . . . . . . . . . . . 29 104 A.7. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 29 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 107 1. Introduction 109 Content Distribution Applications, such as Peer-to-Peer (P2P) 110 applications, are widely used on the Internet to distribute data, and 111 they contribute a large portion of the traffic in many networks. The 112 architecture described in this document enables such applications to 113 leverage in-network storage to achieve more efficient content 114 distribution (i.e. DECADE-compatible system). Specifically, in many 115 subscriber networks, it can be expensive to upgrade network equipment 116 in the "last-mile", because it can involve replacing equipment and 117 upgrading wiring at individual homes, businesses, and devices such as 118 DSLAMs (Digital Subscriber Line Access Multiplexers) and CMTSs (Cable 119 Modem Termination Systems) in remote locations. Therefore, it may be 120 cheaper to upgrade the core infrastructure, which involves fewer 121 components that are shared by many subscribers. See [RFC6646] for a 122 more complete discussion of the problem domain and general 123 discussions of the capabilities to be provided by a DECADE-compatible 124 system. 126 This document presents an architecture for providing in-network 127 storage that can be integrated into Content Distribution 128 Applications. The primary focus is P2P-based content distribution, 129 but the architecture may be useful to other applications with similar 130 characteristics and requirements. See [I-D.ietf-decade-reqs] for a 131 definition of the target applications as well as the requirements for 132 a DECADE-compatible system. 134 The approach of this document is to define the core functionalities 135 and protocol functions that are needed to support a DECADE-compatible 136 system. The specific protocols are not selected or designed in this 137 document. Some illustrative examples are given to help the reader 138 understand certain concepts. These examples are purely informational 139 and are not meant to constrain future protocol design or selection. 141 2. Terminology 143 This document assumes readers are familiar with the terms and 144 concepts that are used in [RFC6646] and [I-D.ietf-decade-reqs]. 146 3. Protocol Flow 148 3.1. Overview 150 Following[I-D.ietf-decade-reqs], the architecture consists of two 151 protocols: the DECADE Resource Protocol (DRP) that is responsible for 152 communication of access control and resource scheduling policies from 153 a client to a server, as well as between servers; and Standard Data 154 Transfer (SDT) protocol(s) that will be used to transfer data objects 155 to and from a server. We show the protocol components figure below: 157 Native Application 158 .-------------. Protocol(s) .-------------. 159 | Application | <------------------> | Application | 160 | End-Point | | End-Point | 161 | | | | 162 | .--------. | | .--------. | 163 | | DECADE | | | | DECADE | | 164 | | Client | | | | Client | | 165 | `--------' | | `--------' | 166 `-------------' `-------------' 167 | ^ | ^ 168 DECADE | | Standard | | 169 Resource | | Data DRP | | SDT 170 Protocol | | Transfer | | 171 (DRP) | | (SDT) | | 172 | | | | 173 | | | | 174 | | | | 175 | | | | 176 | | | | 177 | | | | 178 v V v V 179 .=============. DRP .=============. 180 | DECADE | <------------------> | DECADE | 181 | Server | <------------------> | Server | 182 `=============' SDT `=============' 184 Figure 1: Generic Protocol Flow 186 3.2. An Example 188 This section provides an example showing the steps in the 189 architecture for a data transfer scenario involving an in-network 190 storage system. We assume that Application End-Point B (the 191 receiver) is requesting a data object from Application End-Point A 192 (the sender). Let S(A) denote the DECADE-compatible storage server 193 to which A has access. There are multiple usage scenarios (by choice 194 of the Content Distribution Application). For simplicity of 195 introduction, we design this example to use only a single DECADE- 196 compatible server. 198 The steps of the example are illustrated in Figure 2. First, B 199 requests a data object from A using their native application protocol 200 (see Section 5.1.2). Next, A uses the DRP to obtain a token. There 201 are multiple ways for A to obtain the token: compute locally, or 202 request from its DECADE-compatible storage server, S(A). See 203 Section 6.1.2 for details. A then provides the token to B (again, 204 using their native application protocol). Finally, B provides the 205 token to S(A) via DRP, and requests and downloads the data object via 206 a SDT. 208 .----------. 209 2. Obtain --------> | S(A) | <------ 210 Token / `----------' \ 4. Request and 211 (DRP) / \ Download Data 212 Locally / \ Object 213 or From / \ (DRP + SDT) 214 S(A) v 1. App Request v 215 .-------------. <--------------------------- .-------------. 216 | Application | | Application | 217 | End-Point A | | End-Point B | 218 `-------------' ---------------------------> `-------------' 219 3. App Response (token) 221 Figure 2: Download from Storage Server 223 4. Architectural Principles 225 We identify the following key principles that will be followed in any 226 DECADE-compatible system: 228 4.1. Decoupled Control/Metadata and Data Planes 230 A DECADE-compatible system SHOULD be able to support multiple Content 231 Distribution Applications. A complete Content Distribution 232 Application implements a set of "control plane" functions including 233 content search, indexing and collection, access control, replication, 234 request routing, and QoS scheduling. Different Content Distribution 235 Applications will have unique considerations designing the control 236 plane functions: 238 o Metadata Management Scheme: Traditional file systems provide a 239 standard metadata abstraction: a recursive structure of 240 directories to offer namespace management; each file is an opaque 241 byte stream. Content Distribution Applications may use different 242 metadata management schemes. For example, one application might 243 use a sequence of blocks (e.g., for file sharing), while another 244 application might use a sequence of frames (with different sizes) 245 indexed by time. 247 o Resource Scheduling Algorithms: A major advantage of many 248 successful P2P systems is their substantial expertise in achieving 249 highly efficient utilization of peer and infrastructural 250 resources. For instance, many streaming P2P systems have their 251 specific algorithms in constructing topologies to achieve low- 252 latency, high-bandwidth streaming. They continuously fine-tune 253 such algorithms. 255 Given the diversity of control plane functions, a DECADE-compatible 256 system SHOULD allow as much flexibility as possible to the control 257 plane to implement specific policies. This conforms to the end-to- 258 end systems principle and allows innovation and satisfaction of 259 specific performance goals. 261 Decoupling control plane and data plane is not new. For example, 262 OpenFlow [OpenFlow] is an implementation of this principle for 263 Internet routing, where the computation of the forwarding table and 264 the application of the forwarding table are separated. Google File 265 System [GoogleFileSystem] applies the principle to file system 266 design, by utilizing the Master to handle the meta-data management, 267 and the Chunk servers to handle the data plane functions (i.e., read 268 and write of chunks of data). NFSv4.1's pNFS extension [RFC5661] 269 also implements this principle. 271 4.2. Immutable Data Objects 273 A property of bulk content to be broadly distributed is that they 274 typically are immutable -- once content is generated, it is typically 275 not modified. It is not common that bulk content such as video 276 frames and images need to be modified after distribution. 278 Focusing on immutable data in the data plane can substantially 279 simplify the data plane design, since consistency requirements can be 280 relaxed. It also simplifies reuse of data and implementation of de- 281 duplication. 283 Depending on its specific requirements, an application may store 284 immutable data objects in DECADE-compatible servers such that each 285 data object is completely self-contained (e.g., a complete, 286 independently decodable video segment). An application may also 287 divide data into data objects that require application level 288 assembly. Many Content Distribution Applications divide bulk content 289 into data objects for multiple reasons, including (1) fetching 290 different data objects from different sources in parallel; and (2) 291 faster recovery and verification: individual data objects might be 292 recovered and verified. Typically, applications use a data object 293 size larger than a single packet in order to reduce control overhead. 295 A DECADE-compatible system SHOULD be agnostic to the nature of the 296 data objects and SHOULD NOT specify a fixed size for them. A 297 protocol specification based on this architecture MAY prescribe 298 requirements on minimum and maximum sizes by compliant 299 implementations. 301 Immutable data objects can still be deleted. Applications may 302 support modification of existing data stored at a DECADE-compatible 303 server through a combination of storing new data objects and deleting 304 existing data objects. For example, a meta-data management function 305 of the control plane might associate a name with a sequence of 306 immutable data objects. If one of the data objects is modified, the 307 meta-data management function changes the mapping of the name to a 308 new sequence of immutable data objects. 310 Throughout this document, all data objects are assumed to be 311 immutable. 313 4.3. Data Objects With Identifiers 315 An object that is stored in a DECADE-compatible storage server SHALL 316 be accessed by Content Consumers via a data object identifier. 318 A Content Consumer may be able to access more than one storage 319 server. A data object that is replicated across different storage 320 servers managed by a DECADE-compatible Storage Provider MAY still be 321 accessed by a single identifier. 323 Since data objects are immutable, it SHALL be possible to support 324 persistent identifiers for data objects. 326 Data object identifiers for data objects SHOULD be created by Content 327 Providers that upload the objects to servers. We refer to a scheme 328 for the assignment/derivation of the data object identifier to a data 329 object depends as the data object naming scheme. The details of data 330 naming schemes will be provided by future DECADE-compatible protocol/ 331 naming specifications. This document describes naming schemes on a 332 semantic level and specific SDTs and DRPs SHOULD use specific 333 representations. 335 In particular, for some applications it is important that clients and 336 servers SHOULD be able to validate the name-object binding for a data 337 object, i.e., by verifying that a received object really corresponds 338 to the name (identifier) that was used for requesting it (or that was 339 provided by a sender). Data object identifiers can support name- 340 object binding validation by providing message digests or so-called 341 self-certifying naming information -- if a specific application has 342 this requirement. 344 A DECADE-compatible naming scheme follows the following general 345 requirements: 347 o Different name-object binding validation mechanisms MAY be 348 supported; 350 o Content Distribution Applications will decide what mechanism to 351 use, or to not provide name-object validation (e.g., if 352 authenticity and integrity can by ascertained by alternative 353 means); 355 o Applications MAY be able to construct unique names (with high 356 probability) without requiring a registry or other forms of 357 coordination; and 359 o Names MAY be self-describing so that a receiving entity (Content 360 Consumer) knows what hash function (for example) to use for 361 validating name-object binding. 363 Some Content Distribution Applications will derive the name of a data 364 object from the hash over the data object, which is made possible by 365 the fact that DECADE-compatible objects are immutable. But there may 366 be other applications such as live streaming where object names will 367 not based on hashes but rather on an enumeration scheme. The naming 368 scheme will also enable those applications to construct unique names. 370 In order to enable the uniqueness, flexibility and self-describing 371 properties, the naming scheme SHOULD provide the following name 372 elements: 374 o A "type" field that indicates the name-object validation function 375 type (for example, "sha-256"); 377 o Cryptographic data (such as an object hash) that corresponds to 378 the type information; and 380 The naming scheme MAY additionally provide the following name 381 elements: 383 o Application or publisher information. 385 The specific format of the name (e.g., encoding, hash algorithms, 386 etc) is out of scope of this document, and is left for protocol 387 specification. 389 4.4. Explicit Control 391 To support the functions of an application's control plane, 392 applications SHOULD be able to know and coordinate which data is 393 stored at particular servers. Thus, in contrast with traditional 394 caches, applications are given explicit control over the placement 395 (selection of a DECADE-compatible server), deletion (or expiration 396 policy), and access control for stored data. 398 Consider deletion/expiration policy as a simple example. An 399 application might require that a server stores data objects for a 400 relatively short period of time (e.g., for live-streaming data). 401 Another application might need to store data objects for a longer 402 duration (e.g., for video-on-demand). 404 4.5. Resource and Data Access Control through Delegation 406 A DECADE-compatible system will provide a shared infrastructure to be 407 used by multiple Content Consumers and Content Providers spanning 408 multiple Content Distribution Applications. Thus, it needs to 409 provide both resource and data access control. 411 4.5.1. Resource Allocation 413 There are two primary interacting entities in a DECADE-compatible 414 system. First, Storage Providers SHOULD coordinate where storage 415 servers are provisioned and their total available resources 416 Section 6.1.1. Second, Applications will coordinate data transfers 417 amongst available servers and between servers and clients. A form of 418 isolation is required to enable concurrently-running Applications to 419 each explicitly manage its own data objects and share of resources at 420 the available servers. 422 The Storage Provider SHOULD delegate the management of the resources 423 on a server to Content Providers. This means that Content Providers 424 are able to explicitly and independently manage their own shares of 425 resources on a server. 427 4.5.2. User Delegations 429 Storage Providers will have the ability to explicitly manage the 430 entities allowed to utilize the resources at a DECADE-compatible 431 server. This capability is needed for reasons such as capacity- 432 planning and legal considerations in certain deployment scenarios. 434 The server SHOULD grant a share of the resources to a Content 435 Provider or Content Consumer. The client can in turn share the 436 granted resources amongst its multiple applications. The share of 437 resources granted by a server is called a User Delegation. 439 As a simple example, a DECADE-compatible server operated by an ISP 440 might be configured to grant each ISP Subscriber 1.5 Mbit/s of 441 bandwidth. The ISP Subscriber might in turn divide this share of 442 resources amongst a video streaming application and file-sharing 443 application which are running concurrently. 445 5. System Components 447 The primary focus of this document is the architectural principles 448 and the system components that implement them. While certain system 449 components might differ amongst implementations, the document details 450 the major components and their overall roles in the architecture. 452 To keep the scope narrow, we only discuss the primary components 453 related to protocol development. Particular deployments will require 454 additional components (e.g., monitoring and accounting at a server), 455 but they are intentionally omitted from this document. 457 5.1. Content Distribution Application 459 Content Distribution Applications have many functional components. 460 For example, many P2P applications have components and algorithms to 461 manage overlay topology management, rate allocation, piece selection, 462 etc. In this document, we focus on the components directly employed 463 to support a DECADE-compatible system. 465 Figure 3 illustrates the components discussed in this section from 466 the perspective of a single Application End-Point. 468 Native Protocol(s) 469 (with other Application End-Points) 470 .---------------------> 471 | 472 | 473 .----------------------------------------------------------. 474 | Application End-Point | 475 | .------------. .-------------------. | 476 | | App-Layer | ... | App Data Assembly | | 477 | | Algorithms | | Sequencing | | 478 | `------------' `-------------------' | 479 | | 480 | .------------------------------------------------------. | 481 | | DECADE Client | | 482 | | | | 483 | | .-------------------------. .----------------------. | | 484 | | | Resource Controller | | Data Controller | | | 485 | | | .--------. .----------. | | .--------. .-------. | | | 486 | | | | Data | | Resource | | | | Data | | Data | | | | 487 | | | | Access | | Sharing | | | | Sched. | | Index | | | | 488 | | | | Policy | | Policy | | | | | | | | | | 489 | | | '--------' `----------' | | `--------' `-------' | | | 490 | | `-------------------------' `----------------------' | | 491 | | | ^ | | 492 | `------------ | ----------------- | -------------------' | 493 `-------------- | ----------------- | ---------------------' 494 | | 495 | DECADE | Standard 496 | Resource | Data 497 | Protocol | Transfer 498 | (DRP) | (SDT) 499 v V 501 Figure 3: Application Components 503 5.1.1. Data Assembly 505 A DECADE-compatible system is geared towards supporting applications 506 that can distribute content using data objects. To accomplish this, 507 applications can include a component responsible for creating the 508 individual data objects before distribution and then re-assembling 509 data objects at the Content Consumer. We call this component the 510 Application Data Assembly. 512 In producing and assembling the data objects, two important 513 considerations are sequencing and naming. A DECADE-compatible system 514 assumes that applications implement this functionality themselves. 515 See Section 5.3 for further discussion. 517 5.1.2. Native Application Protocols 519 In addition to the DECADE-compatible DRP/SDT, applications can also 520 support existing native application protocols (e.g., P2P control and 521 data transfer protocols). 523 5.1.3. DECADE Client 525 The client provides the local support to an application, and can be 526 implemented standalone, embedded into the application, or integrated 527 in other entities such as network devices themselves. 529 5.1.3.1. Resource Controller 531 Applications may have different Resource Sharing Policies and Data 532 Access Policies to control their resource and data in DECADE- 533 compatible servers. These policies may be existing policies of 534 applications or custom policies. The specific implementation is 535 decided by the application. 537 5.1.3.2. Data Controller 539 A DECADE-compatible system decouples the control and the data 540 transfer of applications. A Data Scheduling component schedules data 541 transfers according to network conditions, available servers, and/or 542 available server resources. The Data Index indicates data available 543 at remote servers. The Data Index (or a subset of it) can be 544 advertised to other clients. A common use case for this is to 545 provide the ability to locate data amongst distributed Application 546 End-Points (i.e., a data search mechanism such as a Distributed Hash 547 Table). 549 5.2. DECADE Server 551 Figure 4 illustrates the components discussed in a DECADE-compatible 552 server. A server is not necessarily a single physical machine, it 553 can also be implemented as a cluster of machines. 555 | | 556 | DECADE | Standard 557 | Resource | Data 558 | Protocol | Transfer 559 | (DRP) | (SDT) 560 | | 561 .= | ================= | ======================. 562 | | v | 563 | | .----------------. | 564 | |----> | Access Control | <--------. | 565 | | `----------------' | | 566 | | ^ | | 567 | | | | | 568 | | v | | 569 | | .---------------------. | | 570 | `-> | Resource Scheduling | <------| | 571 | `---------------------' | | 572 | ^ | | 573 | | | | 574 | v .------------. | 575 | .-----------------. | User | | 576 | | Data Store | | Delegation | | 577 | `-----------------' | Management | | 578 | DECADE Server `------------' | 579 `==============================================' 581 Figure 4: DECADE Server Components 583 5.2.1. Access Control 585 A client SHALL be able to access its own data or other client's data 586 (provided sufficient authorization) in DECADE-compatible servers. 587 Clients MAY also authorize other clients to store data. If an access 588 is authorized by a client, the server SHOULD provide access. Even if 589 a request is authorized, it MAY still fail to complete due to 590 insufficient resources at the server. 592 5.2.2. Resource Scheduling 594 Applications will apply resource sharing policies or use a custom 595 policy. Servers perform resource scheduling according to the 596 resource sharing policies indicated by clients as well as configured 597 User Delegations. 599 5.2.3. Data Store 601 Data from applications will be stored at a DECADE-compatible server. 602 Data may be deleted from storage either explicitly or automatically 603 (e.g., after a TTL expiration). 605 5.3. Data Sequencing and Naming 607 In order to provide a simple and generic interface, the DECADE- 608 compatible server will be responsible only for storing and retrieving 609 individual data objects. Furthermore, a DECADE-compatible system 610 will use its own naming scheme that provides uniqueness (with high 611 probability) between data objects, even across multiple applications. 613 5.3.1. Data Object Naming Scheme 615 Details of the naming scheme are discussed in Section 5.3. 617 5.3.2. Application Usage 619 Recall from Section 5.1.1 that an Application typically includes its 620 own naming and sequencing scheme. The DECADE-compatible naming 621 format SHOULD NOT attempt to replace any naming or sequencing of data 622 objects already performed by an Application; instead, the naming is 623 intended to apply only to data objects referenced by DECADE-specific 624 purposes. 626 An Application using a DECADE-compatible client may use a naming and 627 sequencing scheme independent of DECADE-compatible names. The 628 DECADE-compatible client SHOULD maintain a mapping from its own data 629 objects and their names to the DECADE-specific data objects and 630 names. Furthermore, the DECADE-compatible naming scheme implies no 631 sequencing or grouping of objects, even if this is done at the 632 application layer. 634 5.3.3. Application Usage Example 636 To illustrate these properties, this section presents multiple 637 examples. 639 5.3.3.1. Application with Fixed-Size Chunks 641 Similar to the example in Section 5.1.1, consider an Application in 642 which each individual application-layer segment of data is called a 643 "chunk" and has a name of the form: "CONTENT_ID:SEQUENCE_NUMBER". 644 Furthermore, assume that the application's native protocol uses 645 chunks of size 16 KiB. 647 Now, assume that this application wishes to store data in DECADE- 648 compatible servers in data objects of size 64 KiB. To accomplish 649 this, it can map a sequence of 4 chunks into a single data object, as 650 shown in Figure 5. 652 Application Chunks 653 .---------.---------.---------.---------.---------.---------.-------- 654 | | | | | | | 655 | Chunk_0 | Chunk_1 | Chunk_2 | Chunk_3 | Chunk_4 | Chunk_5 | Chunk_6 656 | | | | | | | 657 `---------`---------`---------`---------`---------`---------`-------- 659 DECADE Data Objects 660 .---------------------------------------.---------------------------- 661 | | 662 | Object_0 | Object_1 663 | | 664 `---------------------------------------`---------------------------- 666 Figure 5: Mapping Application Chunks to DECADE Data Objects 668 In this example, the Application maintains a logical mapping that is 669 able to determine the name of a DECADE-compatible data object given 670 the chunks contained within that data object. The name may be 671 learned from either the original Content Provider, another End-Point 672 with which the Application is communicating, etc. As long as the 673 data contained within each sequence of chunks is globally unique, the 674 corresponding data objects have globally unique names. 676 5.3.3.2. Application with Continuous Streaming Data 678 Consider an Application whose native protocol retrieves a continuous 679 data stream (e.g., an MPEG2 stream) instead of downloading and 680 redistributing chunks of data. Such an application could segment the 681 continuous data stream to produce either fixed-sized or variable- 682 sized data objects. 684 Figure 6 shows how a video streaming application might produce 685 variable-sized data objects such that each data object contains 10 686 seconds of video data. 688 Application's Video Stream 689 .-------------------------------------------------------------------- 690 | 691 | 692 | 693 `-------------------------------------------------------------------- 694 ^ ^ ^ ^ ^ 695 | | | | | 696 0 Seconds 10 Seconds 20 Seconds 30 Seconds 40 Seconds 697 0 B 400 KiB 900 KiB 1200 KiB 1500 KiB 699 DECADE Data Objects 700 .--------------.--------------.--------------.--------------.-------- 701 | | | | | 702 | Object_0 | Object_1 | Object_2 | Object_3 | 703 | (400 KiB) | (500 KiB) | (300 KiB) | (300 KiB) | 704 `--------------`--------------`--------------`--------------`-------- 706 Figure 6: Mapping a Continuous Data Stream to DECADE Data Objects 708 Similar to the previous example, the Application might maintain a 709 mapping that is able to determine the name of a data object given the 710 time offset of the video chunk. 712 5.4. Token-based Authorization and Resource Control 714 A key feature of a DECADE-compatible system is that a client can 715 authorize other clients to store or retrieve data objects from the 716 in-network storage. A token-based authorization scheme is used to 717 accomplish this. 719 Specifically, an entity trusted by a client generates a signed token 720 with particular properties (see Section 6.1.2 for details). The 721 client then distributes this token to other clients which then use 722 the token when sending requests to the DECADE-compatible server. 723 Upon receiving a token, the server validates the signature and the 724 operation being performed. 726 This is a simple scheme, but has some important advantages over an 727 alternative approach in which a client explicitly manipulates an 728 Access Control List (ACL) associated with each data object. In 729 particular, it has the following advantages when applied to DECADE- 730 compatible target applications: 732 o Authorization policies are implemented within the Application; an 733 Application explicitly controls when tokens are generated and to 734 whom they are distributed and for how long they will be valid. 736 o Fine-grained access and resource control can be applied to data 737 objects; see Section 6.1.2 for the list of restrictions that can 738 be enforced with a token. 740 o There is no messaging between a client and server to manipulate 741 data object permissions. This can simplify, in particular, 742 Applications which share data objects with many dynamic peers and 743 need to frequently adjust access control policies attached to data 744 objects. 746 o Tokens can provide anonymous access, in which a server does not 747 need to know the identity of each client that accesses it. This 748 enables a client to send tokens to clients belonging to other 749 Storage Providers, and allow them to read or write data objects 750 from the storage of its own Storage Provider. 752 In addition to clients applying access control policies to data 753 objects, the server MAY be configured to apply additional policies 754 based on user, object, geographic location, etc. A client might thus 755 be denied access even though it possesses a valid token. 757 There are existing protocols (e.g., OAuth [RFC5849]) that implement 758 similar referral mechanisms using tokens. A protocol specification 759 of this architecture SHOULD endeavor to use existing mechanisms 760 wherever possible. 762 5.5. Discovery 764 A DECADE-compatible system SHOULD include a discovery mechanism 765 through which clients locate an appropriate server. 766 [I-D.ietf-decade-reqs] details specific requirements of the discovery 767 mechanism; this section discusses how they relate to other principles 768 outlined in this document. 770 A discovery mechanism SHOULD allow a client to determine an IP 771 address or some other identifier that can be resolved to locate the 772 server for which the client will be authorized to generate tokens 773 (via DRP). (The discovery mechanism might also result in an error if 774 no such servers can be located.) After discovering one or more 775 servers, a client can distribute load and requests across them 776 (subject to resource limitations and policies of the servers 777 themselves) according to the policies of the Application End-Point in 778 which it is embedded. 780 The particular protocol used for discovery is out of scope of this 781 document, but any specification SHOULD re-use standard protocols 782 wherever possible. 784 The discovery mechanism outlined here does not provide the ability to 785 locate arbitrary DECADE-compatible servers to which a client might 786 obtain tokens from others. To do so will require application-level 787 knowledge, and it is assumed that this functionality is implemented 788 in the Content Distribution Application. 790 6. DECADE Protocols 792 This section presents the DRP and the SDT protocol in terms of 793 abstract protocol interactions that are intended to be mapped to 794 specific protocols. In general, the DRP/SDT functionality between a 795 DECADE-compatible client-server are very similar to the DRP/SDT 796 functionality between server-server. Any differences are highlighted 797 below. 799 DRP will be the protocol used by a DECADE-compatible client to 800 configure the resources and authorization used to satisfy requests 801 (reading, writing, and management operations concerning data objects) 802 at a server. SDT will be used to transport data between a client and 803 a server. 805 6.1. DECADE Resource Protocol (DRP) 807 DRP will provide configuration of access control and resource sharing 808 policies on DECADE-compatible servers. A Content Distribution 809 Application, e.g., a live P2P streaming session, can have permission 810 to manage data at several servers, for instance, servers belonging to 811 different Storage Providers, and DRP allows one instance of such an 812 application, e.g., an Application End-Point, to apply access control 813 and resource sharing policies on each of them. 815 6.1.1. Controlled Resources 817 On a single DECADE-compatible server, the following resources SHOULD 818 be managed: 820 o Communication resources in terms of bandwidth (upload/download) 821 and also in terms of number of active clients (simultaneous 822 connections). 824 o Storage resources. 826 6.1.2. Access and Resource Control Token 828 A token SHOULD include the following information: 830 o Server providing the service; 832 o Permitted operations (e.g., read, write); 834 o Permitted objects (e.g., names of data objects that might be read 835 or written); 837 o Expiration time; 839 o Priority for bandwidth given to requested operation (e.g., a 840 weight used in a weighted bandwidth sharing scheme); 842 o Amount of data that might be read or written. 844 The tokens SHOULD be generated by an entity trusted by both the 845 DECADE-compatible client and server at the request of a DECADE- 846 compatible client. For example this entity could be the client, a 847 server trusted by the client, or another server managed by a Storage 848 Provider and trusted by the client. It is important for a server to 849 trust the entity generating the tokens since each token may incur a 850 resource cost on the server when used. Likewise, it is important for 851 a client to trust the entity generating the tokens since the tokens 852 grant access to the data stored at the server. 854 Upon generating a token, a client MAY distribute it to another client 855 (e.g., via their native application protocol). The receiving client 856 MAY then connect to the server specified in the token and perform any 857 operation permitted by the token. The token SHOULD be sent along 858 with the operation. The server SHOULD validate the token to identify 859 the client that issued it and whether the requested operation is 860 permitted by the contents of the token. If the token is successfully 861 validated, the server SHOULD apply the resource control policies 862 indicated in the token while performing the operation. 864 Tokens SHOULD include a unique identifier to allow a server to detect 865 when a token is used multiple times and reject the additional usage 866 attempts. Since usage of a token incurs resource costs to a server 867 (e.g., bandwidth and storage) and a Content Provider may have a 868 limited budget (see Section 4.5), the Content Provider should be able 869 to indicate if a token may be used multiple times. 871 It SHOULD be possible to revoke tokens after they are generated. 872 This could be accomplished by supplying the server the unique 873 identifiers of the tokens which are to be revoked. 875 6.1.3. Status Information 877 DRP SHOULD provide a status request service that clients can use to 878 request status information of a server. 880 6.1.3.1. Status Information on a specific server 882 Access to such status information SHOULD require client 883 authorization; that is, clients need to be authorized to access the 884 requested status information. This authorization is based on the 885 user delegation concept as described in Section 4.5. The following 886 status information elements SHOULD be obtained: 888 o List of associated data objects (with properties); 890 o Resources used/available. 892 The following information elements MAY additionally be available: 894 o List of servers to which data objects have been distributed (in a 895 certain time-frame); 897 o List of clients to which data objects have been distributed (in a 898 certain time-frame). 900 For the list of servers/clients to which data objects have been 901 distributed to, the server SHOULD be able to decide on time bounds 902 for which this information is stored and specify the corresponding 903 time frame in the response to such requests. Some of this 904 information may be used for accounting purposes, e.g., the list of 905 clients to which data objects have been distributed. 907 6.1.3.2. Access information on a specific server 909 Access information MAY be provided for accounting purposes, for 910 example, when Content Providers are interested in access statistics 911 for resources and/or to perform accounting per user. Again, access 912 to such information requires client authorization and SHOULD based on 913 the delegation concept as described in Section 4.5. The following 914 type of access information elements MAY be requested: 916 o What data objects have been accessed by whom and for how many 917 times; 919 o Access tokens that a server as seen for a given data object. 921 The server SHOULD decide on time bounds for which this information is 922 stored and specify the corresponding time frame in the response to 923 such requests. 925 6.1.4. Data Object Attributes 927 Data Objects that are stored on a DECADE-compatible server SHOULD 928 have associated attributes (in addition to the object identifier and 929 data object) that relate to the data storage and its management. 930 These attributes may be used by the server (and possibly the 931 underlying storage system) to perform specialized processing or 932 handling for the data object, or to attach related server or storage- 933 layer properties to the data object. These attributes have a scope 934 local to a server. In particular, these attributes SHOULD NOT be 935 applied to a server or client to which a data object is copied. 937 Depending on authorization, clients SHOULD be permitted to get or set 938 such attributes. This authorization is based on the delegation 939 concept as described in Section 4.5. The architecture does not limit 940 the set of permissible attributes, but rather specifies a set of 941 baseline attributes that SHOULD be supported: 943 Expiration Time: Time at which the data object can be deleted; 945 Data Object size: In bytes; 947 Media type Labelling of type as per [RFC4288]; 949 Access statistics: How often the data object has been accessed (and 950 what tokens have been used). 952 The data object attributes defined here are distinct from application 953 metadata (see Section 4.1). Application metadata is custom 954 information that an application might wish to associate with a data 955 object to understand its semantic meaning (e.g., whether it is video 956 and/or audio, its playback length in time, or its index in a stream). 957 If an application wishes to store such metadata persistently, it can 958 be stored within data objects themselves. 960 6.2. Standard Data Transfer (SDT) Protocol 962 A DECADE-compatible server will provide a data access interface, and 963 the SDT will be used to write data objects to a server and to read 964 (download) data objects from a server. Semantically, SDT is a 965 client-server protocol; that is, the server always responds to client 966 requests. 968 6.2.1. Writing/Uploading Objects 970 To write a data object, a client first generates the object's name 971 (see Section 5.3), and then uploads the object to a server and 972 supplies the generated name. The name can be used to access 973 (download) the object later; for example, the client can pass the 974 name as a reference to other client that can then refer to the 975 object. 977 Data objects can be self-contained objects such as multimedia 978 resources, files etc., but also chunks, such as chunks of a P2P 979 distribution protocol that can be part of a containing object or a 980 stream. 982 The application that originates the data objects generates DECADE- 983 compatible object names according to the naming specification in 984 Section 5.3. Clients (as parts of application entities) upload a 985 named object to a server. If supported, a server can verify the 986 integrity and other security properties of uploaded objects. 988 6.2.2. Downloading Data Objects 990 A client can request named data objects from a server. In a 991 corresponding request message, a client specifies the object name and 992 a suitable access and resource control token. The server checks the 993 validity of the received token and its associated resource usage- 994 related properties. 996 If the named data object exists on the server and the token can be 997 validated, the server delivers the requested object in a response 998 message. 1000 If the data object cannot be delivered the server provides an 1001 corresponding status/reason information in a response message. 1003 Specifics regarding error handling, including additional error 1004 conditions (e.g., overload), precedence for returned errors and its 1005 relation with server policy, are deferred to eventual protocol 1006 specification. 1008 6.3. Server-to-Server Protocols 1010 An important feature of a DECADE-compatible system is the capability 1011 for one server to directly download data objects from another server. 1012 This capability allows Applications to directly replicate data 1013 objects between servers without requiring end-hosts to use uplink 1014 capacity to upload data objects to a different server. 1016 DRP and SDT will support operations directly between servers. 1017 Servers are not assumed to trust each other nor are configured to do 1018 so. All data operations are performed on behalf of clients via 1019 explicit instruction. However, the objects being processed do not 1020 necessarily have to originate or terminate at the client (i.e., the 1021 data object might be limited to being exchanged between servers even 1022 if the instruction is triggered by the client). Clients thus will be 1023 able to indicate to a server the following additional parameters: 1025 o Which remote server(s) to access; 1027 o The operation to be performed; 1029 o The Content Provider at the remote server from which to retrieve 1030 the data object, or in which the object is to be stored; and 1032 o Credentials indicating access and resource control to perform the 1033 operation at the remote server. 1035 Server-to-server support is focused on reading and writing data 1036 objects between servers. The data object referred to at the remote 1037 server is the same as the original data object requested by the 1038 client. Object attributes (see Section 6.1.4) might also be 1039 specified in the request to the remote server. 1041 In this way, a server acts as a proxy for a client, and a client can 1042 instantiate requests via that proxy. The operations will be 1043 performed as if the original requester had its own client co-located 1044 with the server. 1046 When a client sends a request to a server with these additional 1047 parameters, it is giving the server permission to act (proxy) on its 1048 behalf. Thus, it would be prudent for the supplied token to have 1049 narrow privileges (e.g., limited to only the necessary data objects) 1050 or validity time (e.g., a small expiration time). 1052 In the case of a retrieval operation, the server is to retrieve the 1053 data object from the remote server using the specified credentials, 1054 and then optionally return the object to a client. In the case of a 1055 storage operation, the server is to store the object to the remote 1056 server using the specified credentials. The object might optionally 1057 be uploaded from the client or might already exist at the proxy 1058 server. 1060 7. Security Considerations 1062 In general, the security considerations mentioned in [RFC6646] apply 1063 to this document as well. 1065 A DECADE-compatible system provides a distributed storage service for 1066 content distribution and similar applications. The system consists 1067 of servers and clients that use these servers to upload data objects, 1068 to request distribution of data objects, and to download data 1069 objects. Such a system is employed in an overall application context 1070 -- for example in a P2P Content Distribution Application, and it is 1071 expected that DECADE-compatible clients take part in application- 1072 specific communication sessions. 1074 The security considerations here focus on threats related to the 1075 DECADE-compatible system and its communication services, i.e., the 1076 DRP/SDT protocols that have been described in an abstract fashion in 1077 this document. 1079 7.1. Threat: System Denial of Service Attacks 1081 A DECADE-compatible network might be used to distribute data objects 1082 from one client to a set of servers using the server-to-server 1083 communication feature that a client can request when uploading an 1084 object. Multiple clients uploading many objects at different servers 1085 at the same time and requesting server-to-server distribution for 1086 them could thus mount massive distributed denial of service (DDOS) 1087 attacks, overloading a network of servers. 1089 This threat is addressed by the server's access control and resource 1090 control framework. Servers can require Application End-Points to be 1091 authorized to store and to download objects, and Application End- 1092 Points can delegate authorization to other Application End-Points 1093 using the token mechanism. 1095 Of course the effective security of this approach depends on the 1096 strength of the token mechanism. See below for a discussion of this 1097 and related communication security threats. 1099 Denial of Service Attacks against a single server (directing many 1100 requests to that server) might still lead to considerable load for 1101 processing requests and invalidating tokens. SDT therefore MUST 1102 provide a redirection mechanism as described as a requirement in 1103 [I-D.ietf-decade-reqs]. 1105 7.2. Threat: Protocol Security 1107 7.2.1. Threat: Authorization Mechanisms Compromised 1109 A DECADE-compatible system does not require Application End-Points to 1110 authenticate in order to access a server for downloading objects, 1111 since authorization is not based on End-Point or user identities but 1112 on the delegation-based authorization mechanism. Hence, most 1113 protocol security threats are related to the authorization scheme. 1115 The security of the token mechanism depends on the strength of the 1116 token mechanism and on the secrecy of the tokens. A token can 1117 represent authorization to store a certain amount of data, to 1118 download certain objects, to download a certain amount of data per 1119 time etc. If it is possible for an attacker to guess, construct or 1120 simply obtain tokens, the integrity of the data maintained by the 1121 servers is compromised. 1123 This is a general security threat that applies to authorization 1124 delegation schemes. Specifications of existing delegation schemes 1125 such as OAuth [RFC5849] discuss these general threats in detail. We 1126 can say that the DRP has to specify appropriate algorithms for token 1127 generation. Moreover, authorization tokens should have a limited 1128 validity period that should be specified by the application. Token 1129 confidentiality should be provided by application protocols that 1130 carry tokens, and the SDT and DRP should provide secure 1131 (confidential) communication modes. 1133 7.2.2. Threat: Data Object Spoofing 1135 In a DECADE-compatible system, an Application End-Point is referring 1136 other Application End-Points to servers to download a specified data 1137 objects. An attacker could "inject" a faked version of the object 1138 into this process, so that the downloading End-Point effectively 1139 receives a different object (compared to what the uploading End-Point 1140 provided). As result, the downloading End-Point believes that is has 1141 received an object that corresponds to the name it was provided 1142 earlier, whereas in fact it is a faked object. Corresponding attacks 1143 could be mounted against the application protocol (that is used for 1144 referring other End-Points to servers), servers themselves (and their 1145 storage sub-systems), and the SDT by which the object is uploaded, 1146 distributed and downloaded. 1148 A DECADE-compatible systems fundamental mechanism against object 1149 spoofing is name-object binding validation, i.e., the ability of a 1150 receiver to check whether the name he was provided and that he used 1151 to request an object, actually corresponds to the bits he received. 1152 As described above, this allows for different forms of name-object 1153 binding, for example using hashes of data objects, with different 1154 hash functions (different algorithms, different digest lengths). For 1155 those application scenarios where hashes of data objects are not 1156 applicable (for example live-streaming) other forms of name-object 1157 binding can be used (see Section 5.3). This flexibility also 1158 addresses cryptographic algorithm evolvability: hash functions might 1159 get deprecated, better alternatives might be invented etc., so that 1160 applications can choose appropriate mechanisms meeting their security 1161 requirements. 1163 DECADE-compatible servers MAY perform name-object binding validation 1164 on stored objects, but Application End-Points MUST NOT rely on that. 1165 In other words, Application End-Points SHOULD perform name-object 1166 binding validation on received objects. 1168 8. IANA Considerations 1170 This document does not have any IANA considerations. 1172 9. Acknowledgments 1174 We thank the following people for their contributions to this 1175 document: 1177 David Bryan 1179 Dave Crocker 1181 Yingjie Gu 1183 Hongqiang (Harry) Liu 1185 David McDysan 1187 Borje Ohlman 1189 Konstantinos Pentikousis 1191 Haibin Song 1193 Martin Stiemerling 1195 Richard Woundy 1197 Ning Zong 1199 10. References 1200 10.1. Normative References 1202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1203 Requirement Levels", BCP 14, RFC 2119, March 1997. 1205 10.2. Informative References 1207 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1208 Registration Procedures", BCP 13, RFC 4288, December 2005. 1210 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 1211 System (NFS) Version 4 Minor Version 1 Protocol", 1212 RFC 5661, January 2010. 1214 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 1215 April 2010. 1217 [RFC6392] Alimi, R., Rahman, A., and Y. Yang, "A Survey of In- 1218 Network Storage Systems", RFC 6392, October 2011. 1220 [RFC6646] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled 1221 Application Data Enroute (DECADE) Problem Statement", 1222 RFC 6646, July 2012. 1224 [I-D.ietf-decade-reqs] 1225 Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE 1226 Requirements", draft-ietf-decade-reqs-06 (work in 1227 progress), March 2012. 1229 [OpenFlow] 1230 "OpenFlow Organization", . 1232 [GoogleFileSystem] 1233 Ghemawat, S., Gobioff, H., and S. Leung, "The Google File 1234 System", SOSP 2003, October 2003. 1236 Appendix A. In-Network Storage Components Mapped to DECADE Architecture 1238 In this section we evaluate how the basic components of an in-network 1239 storage system identified in Section 3 of [RFC6392] map into a 1240 DECADE-compatible system. 1242 A.1. Data Access Interface 1244 Clients can read and write objects of arbitrary size through the 1245 client's Data Controller, making use of a SDT. 1247 A.2. Data Management Operations 1249 Clients can move or delete previously stored objects via the client's 1250 Data Controller, making use of a SDT. 1252 A.3. Data Search Capability 1254 Clients can enumerate or search contents of servers to find objects 1255 matching desired criteria through services provided by the Content 1256 Distribution Application (e.g., buffer-map exchanges, a DHT, or peer- 1257 exchange). In doing so, Application End-Points might consult their 1258 local Data Index in the client's Data Controller. 1260 A.4. Access Control Authorization 1262 All methods of access control are supported: public-unrestricted, 1263 public-restricted and private. Access Control Policies are generated 1264 by a Content Distribution Application and provided to the client's 1265 Resource Controller. The server is responsible for implementing the 1266 access control checks. 1268 A.5. Resource Control Interface 1270 Clients can manage the resources (e.g., bandwidth) on the DECADE 1271 server that can be used by other Application End-Points. Resource 1272 Sharing Policies are generated by a Content Distribution Application 1273 and provided to the client's Resource Controller. The server is 1274 responsible for implementing the resource sharing policies. 1276 A.6. Discovery Mechanism 1278 The particular protocol used for discovery is outside the scope of 1279 this document. However, options and considerations have been 1280 discussed in Section 5.5. 1282 A.7. Storage Mode 1284 Servers provide an object-based storage mode. Immutable data objects 1285 might be stored at a server. Applications might consider existing 1286 blocks as data objects, or they might adjust block sizes before 1287 storing in a server. 1289 Authors' Addresses 1291 Richard Alimi 1292 Google 1294 Email: ralimi@google.com 1296 Akbar Rahman 1297 InterDigital Communications, LLC 1299 Email: akbar.rahman@interdigital.com 1301 Dirk Kutscher 1302 NEC 1304 Email: dirk.kutscher@neclab.eu 1306 Y. Richard Yang 1307 Yale University 1309 Email: yry@cs.yale.edu