idnits 2.17.1 draft-ohlman-decade-add-use-cases-reqs-02.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2010) is 4925 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission B. Ohlman 3 Internet-Draft Ericsson 4 Intended status: Informational O. Strandberg 5 Expires: April 28, 2011 Nokia Siemens Networks 6 C. Dannewitz 7 University of Paderborn 8 A. Lindgren 9 SICS 10 R. Maglione 11 Telecom Italia 12 B. Ahlgren 13 SICS 14 D. Kutscher 15 NEC 16 October 25, 2010 18 Requirements for accessing data in network storage 19 draft-ohlman-decade-add-use-cases-reqs-02 21 Abstract 23 The DECoupled Application Data Enroute (DECADE) working group is 24 specifying standardized interfaces for accessing in-network storage 25 from applications to store, retrieve and manage data. The main 26 objective is to provide a framework that is useful to P2P 27 applications, without excluding other, possibly related applications 28 that can benefit from accessing in-network storage. This memo 29 presents Internet TV as a specific application scenario where access 30 to in-netork storage would be required and lists a set of concrete 31 requirements that should be considered for the DECADE architecture 32 and protocol specifications. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in [RFC2119]. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 28, 2011. 57 Copyright Notice 59 Copyright (c) 2010 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 This document may contain material from IETF Documents or IETF 73 Contributions published or made publicly available before November 74 10, 2008. The person(s) controlling the copyright in some of this 75 material may not have granted the IETF Trust the right to allow 76 modifications of such material outside the IETF Standards Process. 77 Without obtaining an adequate license from the person(s) controlling 78 the copyright in such materials, this document may not be modified 79 outside the IETF Standards Process, and derivative works of it may 80 not be created outside the IETF Standards Process, except to format 81 it for publication as an RFC or to translate it into languages other 82 than English. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 87 2. Internet TV Scenario . . . . . . . . . . . . . . . . . . . . . 5 88 2.1. Detailed Scenario Description . . . . . . . . . . . . . . . 5 89 2.2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 6 90 3. Specific requirements . . . . . . . . . . . . . . . . . . . . . 6 91 3.1. Unique Naming of Information Objects . . . . . . . . . . . 6 92 3.1.1. Requirement . . . . . . . . . . . . . . . . . . . . . . 6 93 3.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 7 94 3.1.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 7 95 3.2. Access to Information Objects . . . . . . . . . . . . . . . 7 96 3.2.1. Requirement . . . . . . . . . . . . . . . . . . . . . . 7 97 3.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 7 98 3.2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 7 99 3.3. Real-time Support . . . . . . . . . . . . . . . . . . . . . 7 100 3.3.1. Requirement . . . . . . . . . . . . . . . . . . . . . . 7 101 3.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 7 102 3.3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 8 103 3.4. Discovery service for DECADE in-network storage . . . . . . 8 104 3.4.1. Requirement . . . . . . . . . . . . . . . . . . . . . . 8 105 3.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 8 106 3.4.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 8 107 3.5. Multiple active DECADE Storage Servers . . . . . . . . . . 8 108 3.5.1. Requirement . . . . . . . . . . . . . . . . . . . . . . 8 109 3.5.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 8 110 3.5.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 8 111 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 112 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 113 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 114 7. Informative References . . . . . . . . . . . . . . . . . . . . 9 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 117 1. Introduction 119 The DECADE approach to access to in-network storage through 120 standardized interfaces has been motivated by P2P application 121 scenarios where it can be beneficial to refer peers to in-network 122 storage system in a convenient network-topological location in order 123 to enhance data exchange for a given P2P application. 125 One specific example would be a P2P application instance in a home 126 network connected via an ADSL access network. In a traditional P2P 127 approach, this application instance would download chunks from other 128 peers and serve chunks to other peers in parallel. With an 129 asymmetric uplink, the application instance (and other hosts on the 130 home network) are likely to experience uplink congestion, if the 131 application instance is selected by a substantial number of peers and 132 has to serve data to them. In situations with prevalent asymmetric 133 access links, the P2P session (all peer application instances) would 134 also be limited in the achievable downlink speed because the 135 aggregate uplink bandwidth is not sufficient. 137 DECADE in-network storage servers are expected to be helpful in such 138 scenarios, because peers could be referred to appropriate storage 139 servers for downloading some content, thereby offloading traffic from 140 the capacity-limited access uplinks. 142 Such storage servers are expected to provide interfaces for storing, 143 retrieving, and managing data. The general concept is that, in a 144 distributed P2P application, some instance would upload data to a 145 storage server and then refer other instances, such as P2P peers, to 146 that data, for instance by passing a certain URI. In addition, there 147 could be interactions for allocating capacity on servers for certain 148 applications, for deleting data etc. 150 This document argues that, while such a system would be very useful 151 for P2P applications, there are others, related applications that 152 could benefit from in-network storage in just the same way. Though 153 only applications that does not lead to a completely new set of 154 requirements should be taken into account. This document argues that 155 it should be possible to extend the DECADE work to include certain 156 other applications without increasing the overall complexity of the 157 solution. 159 Specifically, this document describes the in-network-storage aspects 160 of Internet TV -- an important application today, that can 161 significantly benefit from in-network-caching. We argue that it 162 seems negligent to exclude Internet TV from leveraging DECADE in- 163 network-storage and describe specific use cases for accessing in- 164 network-storage in such a scenario. Moreover, we present a set of 165 requirements that should be met by the DECADE architecture design in 166 order guarantee its applicability to such applications. We propose 167 that these requirements be added to the DECADE requirements 168 specification. 170 In this memo, we align the requirement description to the layout used 171 in [I-D.gu-decade-reqs]. Section 2 describes the Internet TV 172 scenario, and Section 3 presents corresponding requirements that 173 should be considered to ensure a broad enough applicability of the 174 DECADE framework. 176 2. Internet TV Scenario 178 Internet TV is a general term to refer to different kinds of systems 179 or applications where video is delivered to (mostly) home network 180 devices for immediate rendering or storing. In this memo, we refer 181 to the distribution of video content, mainly focusing on Video-on- 182 Demand (VoD) services and user-generated content. 184 VoD services are commonly widespread in many service providers' 185 networks. This scenario is characterized by the need to support an 186 efficient large-scale distribution of video, possibly with a fairly 187 high degree of replicated contents, to a multiplicity of fixed and 188 mobile users. By supporting this application with DECADE protocols, 189 video content can be retrieved from the in-network storage, achieving 190 a number of benefits. The originating servers can be relieved from 191 most of the load, since popular content will be automatically 192 available in the in-network storage, closer to the users. Improved 193 network efficiency will be achieved, reducing the traffic load in the 194 upstream network segments. Moreover user experience, also for mobile 195 users, can be improved. 197 2.1. Detailed Scenario Description 199 A well-known issue with Internet TV applications such as YouTube is 200 the flash crowd problem. That is also an example of a problem which 201 could be significantly eased if in-network storage is used to provide 202 users with locally available copies rather than all requesting the 203 data from the source. This can be extra beneficial for services with 204 real-time (or near real-time) components as traditional pre-caching 205 solutions can be difficult to use then. 207 A particular interesting Internet TV variant is "hybrid Internet TV" 208 based on an Internet TV distribution service that is a hybrid between 209 traditional CDN and a P2P service. Such a service would distribute 210 content from central servers, make use of CDN caches on the way and 211 finally use the end hosts/STB as caches for the P2P part of the 212 application. 214 If only the P2P application in the host/STB can store content in the 215 DECADE storage, the content first has to be downloaded from the 216 Internet TV server/CDN cache over the access link to the host/STB and 217 then uploaded, over the same access link, to the DECADE storage 218 before any peer in the P2P part of the application can access it from 219 the DECADE storage (instead of downloading it from the client). 221 To avoid this, it should be possible for the DECADE storage to 222 'cache' the content when the first download to the host/STB is done. 223 That would mean the content never have to travel over the capacity- 224 limited uplink. For this to be feasible, one requirement is that the 225 Internet TV service can prompt the DECADE storage that certain 226 content should be cached on its way to the host. Having such 227 functionality, that allows a host to get content from the DECADE 228 storage of neighboring host rather than from a central server, would 229 of course also offload the core network in the same way a traditional 230 CDN does. 232 2.2. Summary 234 The DECADE architecture and protocol specifications should take the 235 hybrid Internet TV scenario into account to ensure a reasonable level 236 of generality of the DECADE in-network storage. While P2P-specific 237 requirements should be considered, DECADE should not be unnecessarily 238 limited to it. 240 Specifically, dissemination applications of streaming type (some with 241 real-time or close to real-time requirements) should be supported by 242 DECADE as they can cause significant load on the network. The 243 network load could be reduced significantly for these types of 244 applications if copies stored locally in the network could be used 245 instead of always fetching data from the source. 247 3. Specific requirements 249 3.1. Unique Naming of Information Objects 251 3.1.1. Requirement 253 When a DECADE client in a certain application context stores an 254 information object in DECADE storage servers, the object MUST be 255 addressable by a unique name across different application contexts. 257 3.1.2. Rationale 259 There is a need for unique naming to enable different application 260 instances to refer to information objects using a name (that may have 261 been provided to them by another DECADE client). Such unique naming 262 is essential for efficient cache handling and can serve for de- 263 duplication. 265 3.1.3. Discussion 267 Unique naming can be achieved in different ways. Names can assigned 268 from some (structured) names, for instance by URIs. Names can also 269 be generated, for instance by calculating hashes of the object's 270 content. 272 The detailed syntax and semantics of DECADE names (and the actual 273 standardization requirements) are for further study. 275 3.2. Access to Information Objects 277 3.2.1. Requirement 279 It MUST be possible to access data stored on DECADE storage servers 280 as complete information objects, such as a named video file. 282 3.2.2. Rationale 284 In a video-on-demand caching use case, the client application should 285 be enabled to retrieve the complete object in one transaction and 286 should not be required to download individual chunks. 288 3.2.3. Discussion 290 This does not necessarily impose implications on the way that the 291 storage servers stores the object. 293 3.3. Real-time Support 295 3.3.1. Requirement 297 The DECADE storage service MUST support real-time applications in a 298 way that a resource that is being uploaded is already available for 299 download. 301 3.3.2. Rationale 303 For larger objects or chunks, it is not acceptable if a DECADE client 304 has to upload the complete resource first, before other clients can 305 start downloading it. 307 3.3.3. Discussion 309 This requirement should also be important for P2P live streaming. 311 3.4. Discovery service for DECADE in-network storage 313 3.4.1. Requirement 315 When a DECADE client attach to a DECADE enabled network there SHOULD 316 be a discovery service that can tell a DECADE client where in-network 317 storage servers can be found. 319 3.4.2. Rationale 321 To minimize manual configuration of the DECADE clients, a discovery 322 service, similar to DHCP , should be provided in the DECADE enabled 323 network. 325 3.4.3. Discussion 327 In particular, this simplifies the administration of the DECADE in- 328 network storage for a user that roams to a visited network. 330 3.5. Multiple active DECADE Storage Servers 332 3.5.1. Requirement 334 A DECADE client SHOULD be able to use multiple in-network storage 335 servers at the same time. 337 3.5.2. Rationale 339 One example of when this is needed is when a user/client roams to 340 another network, then it is reasonable to assume that the currently 341 used in-network storage remains active for a certain time not to 342 disrupt ongoing communication sessions at the same time as another 343 in-network storage might immediately be needed in the new network. 345 3.5.3. Discussion 347 A user of DECADE in-network storage who roams to a visited network 348 could potentially cause very inefficient access to that user's DECADE 349 storage. It is therefore essential that the user is able to acquire 350 new DECADE storage which is better located in the visited network. 351 Usage that could result in such inefficiencies is communication with 352 other users locally in the same network, for example as part of a 353 small meeting or large event (fair, sports event, etc). 355 A related issue is the possibility to migrate content from one DECADE 356 storage to another when roaming. We believe that this is covered by 357 the requirements on Efficient Transfer (section 3.3) and 358 Communication among In-network Storage Elements (section 4.3) of 359 [I-D.gu-decade-reqs]. 361 4. IANA Considerations 363 This document has no requests to IANA. 365 5. Security Considerations 367 The re-use of copies in the network part of DECADE will require that 368 appropriate access control mechanisms are designed. 370 6. Acknowledgments 372 We would like to thank all persons participating in the Network of 373 Information work package in the EU FP7 projects 4WARD and SAIL for 374 contributions and feedback to this document. 376 7. Informative References 378 [I-D.gu-decade-reqs] 379 Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE 380 Requirements", draft-gu-decade-reqs-05 (work in progress), 381 July 2010. 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 Authors' Addresses 388 Borje Ohlman 389 Ericsson 390 Stockholm 391 Sweden 393 Email: Borje.Ohlman@ericsson.com 394 Ove Strandberg 395 Nokia Siemens Networks 396 Linnoitustie 6 397 Espoo 398 Finland 400 Email: ove.strandberg@nsn.com 402 Christian Dannewitz 403 University of Paderborn 404 Paderborn 405 Germany 407 Email: cdannewitz@upb.de 409 Anders Lindgren 410 Swedish Institute of Computer Science 411 Stockholm 412 Sweden 414 Email: andersl@sics.se 416 Roberta Maglione 417 Telecom Italia 418 Turin 419 Italy 421 Email: roberta.maglione@telecomitalia.it 423 Bengt Ahlgren 424 Swedish Institute of Computer Science 425 Stockholm 426 Sweden 428 Email: bengta@sics.se 429 Dirk Kutscher 430 NEC Laboratories Europe 431 Kurfuersten-Anlage 36 432 Heidelberg 433 Germany 435 Email: kutscher@neclab.eu