idnits 2.17.1 draft-ohlman-decade-add-use-cases-reqs-01.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 (July 9, 2010) is 5041 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-gu-decade-reqs-04 Summary: 0 errors (**), 0 flaws (~~), 3 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: January 10, 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 July 9, 2010 16 Requirements for accessing data in network storage 17 draft-ohlman-decade-add-use-cases-reqs-01 19 Abstract 21 So far, the intended scope of the DECoupled Application Data Enroute 22 (DECADE) working group has mainly been focused on peer-to-peer (P2P) 23 applications. There are however many non-P2P-based applications that 24 could also benefit from in-network storage for caching content. The 25 target of DECADE should thus be to specify a mechanism that is also 26 suitable for generic applications with certain characteristics and 27 not only P2P applications. This document enumerates a number of 28 requirements that should be considered during the design and 29 implementation of this mechanism. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 10, 2011. 54 Copyright Notice 56 Copyright (c) 2010 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 This document may contain material from IETF Documents or IETF 70 Contributions published or made publicly available before November 71 10, 2008. The person(s) controlling the copyright in some of this 72 material may not have granted the IETF Trust the right to allow 73 modifications of such material outside the IETF Standards Process. 74 Without obtaining an adequate license from the person(s) controlling 75 the copyright in such materials, this document may not be modified 76 outside the IETF Standards Process, and derivative works of it may 77 not be created outside the IETF Standards Process, except to format 78 it for publication as an RFC or to translate it into languages other 79 than English. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 2. General principles . . . . . . . . . . . . . . . . . . . . . . 4 85 2.1. Application-agnostic . . . . . . . . . . . . . . . . . . . 5 86 2.1.1. Requirement . . . . . . . . . . . . . . . . . . . . . . 5 87 2.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 5 88 2.2. Data reuse . . . . . . . . . . . . . . . . . . . . . . . . 5 89 2.2.1. Requirement . . . . . . . . . . . . . . . . . . . . . . 5 90 2.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 5 91 2.2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 6 92 3. Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . 6 93 3.1. Roaming users . . . . . . . . . . . . . . . . . . . . . . . 6 94 3.1.1. Requirement . . . . . . . . . . . . . . . . . . . . . . 6 95 3.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 6 96 3.1.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 7 97 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 98 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 99 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 100 7. Informative References . . . . . . . . . . . . . . . . . . . . 7 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 103 1. Introduction 105 This draft suggests that DECADE should provide an application 106 agnostic network storage mechanism that not only supports P2P 107 applications. To ensure this we suggest to extend the scope of 108 DECADE to include at least one use case besides the P2P use case. 109 This second use case could for example be IPTV, but other alternative 110 proposals that can represent the main characteristics of popular 111 dissemination applications could also be used. This draft also wants 112 to make sure that requirements on the possibility of data reuse of 113 cached copies in the network and of support for mobility are included 114 in the WG charter. Thus the goal of this draft is to address some 115 generic requirements that should be supported by in-network storage, 116 both from an application and a use case situation point of view. 118 This draft recognizes that DECADE have complementary requirements in 119 the updated draft; [I-D.gu-decade-reqs] and aligns the layout 120 accordingly. 122 This document enumerates and explains the rationale behind additional 123 requirements that should be considered in the specification of a 124 protocol for DECADE. 126 2. General principles 128 Other applications than P2P should be supported by DECADE, especially 129 dissemination applications of streaming type (some with real-time or 130 close to real-time requirements) as they can cause significant load 131 on the network. The network load could be reduced significantly for 132 these types of applications if copies stored locally in the network 133 could be used instead of always fetching data from the source. 135 A scenario that we are considering of a particular interest in this 136 respect is represented by the IPTV use case. By IPTV we are 137 referring here to the distribution of video content, mainly focusing 138 on Video-on-Demand (VoD) services and user-generated contents. VoD 139 services are commonly widespread in many Service Provider's networks. 140 This scenario is characterized by the need to support an efficient 141 large-scale distribution of video, possibly with a fairly high degree 142 of replicated contents, to a multiplicity of fixed and mobile users. 143 By supporting this application with the DECADE protocols, video 144 content can be retrieved from the in-network storage, achieving a 145 number of benefits. The originating servers can be relieved from 146 most of the load, since popular content will be automatically 147 available in the in-network storage, closer to the users. Improved 148 network efficiency will be achieved, reducing the traffic load in the 149 upstream network segments. Moreover user experience, including 150 mobile ones, can also be improved. 152 2.1. Application-agnostic 154 2.1.1. Requirement 156 The specification of DECADE SHOULD strive to make the DECADE in- 157 network storage application-agnostic. As a verification of this 158 effort DECADE SHOULD be specified in such a way that it can address 159 at least one other application type, besides P2P applications. 161 2.1.2. Rationale 163 The currently proposed DECADE charter mainly addresses P2P 164 applications. However, there are other applications that also have 165 large footprint in the network load and could benefit from the work 166 done in DECADE. There is no need to address the requirements of all 167 types of applications but it should be ensured that DECADE implements 168 generic properties that are reasonably application agnostic. In 169 order to make sure that this is the case, it is proposed that at 170 least one more application type is taken into account. An example of 171 such an application could be large-scale video distribution such as 172 IPTV, YouTube, etc. A well-known issue with these applications is 173 the problem with flash crowds. That is also an example of a problem 174 which could be significantly eased if in-network storage is used to 175 provide users with locally available copies rather than all 176 requesting the data from the source (as outlined below in 177 Section 2.2). This can be extra beneficial for services with 178 realtime (or near realtime) components as traditional pre-caching 179 solutions can be difficult to use then. 181 2.2. Data reuse 183 2.2.1. Requirement 185 When certain content is popular and used by many users, the network 186 part of DECADE SHOULD be able to store only one (or any limited 187 number) copy of that data. The same data can then be used to serve 188 requests from multiple DECADE users. 190 2.2.2. Rationale 192 For an application like IPTV it is clear that multiple users will 193 request the same content, and thus wish to store multiple copies of 194 the same content in the in-network storage using DECADE. For these, 195 often very large, data objects it is clear that significant resources 196 can be saved in the network if a limited number of copies can be 197 stored in, for the network, strategic locations such that the usage 198 of storage and transmission resources are optimized. By only storing 199 a single copy of the data at each node, the storage requirements can 200 be greatly reduced. It has also been shown that there are strong 201 locality characteristics among requests for this type of content as 202 it's popularity often spreads through social networks or through a 203 geographic region [yoneki_09][gill_07]. This indicates that the 204 potential savings are very large. Well established use of web 205 proxies also indicates that data reuse can be a potential key 206 feature. 208 2.2.3. Discussion 210 To make it possible to reuse content in other in-network storage 211 locations than the one originally requested there are two important 212 requirements that needs to be fulfilled. The first is that the 213 content is named in such a way that copies can be identified in other 214 in network storage locations. To facilitate this content should be 215 named in an application independent way. The second requirement is 216 that if you ask for a certain named content you must be able to 217 verify that the content returned really is the content associated 218 with that name by the original publisher of the content. This 219 property can be achieved by securely binding the name to the content, 220 e.g., by including the hash of the content in the name, or with a 221 signature, creating self-certifying names. 223 In combination with the application-agnostic requirement, the data 224 reuse requirement means that it should be possible to make use of the 225 same cached data copy through more than one application protocol, for 226 example, BitTorrent or HTTP (provided that they are appropriately 227 modified, if needed). 229 3. Data Access 231 3.1. Roaming users 233 3.1.1. Requirement 235 DECADE SHOULD have the ability to support roaming for terminals/ 236 users/applications by allowing the use of in-network storage in the 237 visited network. 239 3.1.2. Rationale 241 A user of DECADE in-network storage that roams to a visited network 242 could potentially cause very inefficient access to that user's DECADE 243 storage. It is therefore essential that the user is able to acquire 244 new DECADE storage which is better located in the visited network. 246 Usage that could result in such inefficiencies is communication with 247 other users locally in the same network, for example as part of a 248 small meeting or large event (fair, sports event, etc). 250 3.1.3. Discussion 252 A related issue is the possibility to migrate content from one DECADE 253 storage to another when roaming. We believe that this is covered by 254 the requirements on Efficient Transfer (section 3.3) and 255 Communication among In-network Storage Elements (section 4.3) of 256 [I-D.gu-decade-reqs]. 258 4. IANA Considerations 260 This document has no requests to IANA. 262 5. Security Considerations 264 The re-use of copies in the network part of DECADE will require that 265 appropriate access control mechanisms are designed. 267 6. Acknowledgements 269 We would like to thank all persons participating in the Network of 270 Information work package in the EU FP7 project 4WARD for 271 contributions and feedback to this document. 273 7. Informative References 275 [I-D.gu-decade-reqs] 276 Yingjie, G., Yongchao, S., Yang, Y., and R. Alimi, "DECADE 277 Requirements", draft-gu-decade-reqs-04 (work in progress), 278 March 2010. 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [gill_07] Gill, P., Arlitt, M., Li, Z., and A. Mahanti, "Youtube 284 traffic characterization: a view from the edge", 285 Proceedings of the 7th ACM SIGCOMM conference on Internet 286 measurement , 2007. 288 [yoneki_09] 289 Yoneki, E., Sastry, N., and J. Crowcroft, "Buzztraq: 291 predicting geographical access patterns of social cascades 292 using social networks", Proceedings of the Second ACM 293 EuroSys Workshop on Social Network Systems , 2009. 295 Authors' Addresses 297 Borje Ohlman 298 Ericsson 299 Stockholm 300 Sweden 302 Email: Borje.Ohlman@ericsson.com 304 Ove Strandberg 305 Nokia Siemens Networks 306 Espoo 307 Finland 309 Email: ove.strandberg@nsn.com 311 Christian Dannewitz 312 University of Paderborn 313 Paderborn 314 Germany 316 Email: cdannewitz@upb.de 318 Anders Lindgren 319 Swedish Institute of Computer Science 320 Stockholm 321 Sweden 323 Email: andersl@sics.se 325 Roberta Maglione 326 Telecom Italia 327 Turin 328 Italy 330 Email: roberta.maglione@telecomitalia.it 331 Bengt Ahlgren 332 Swedish Institute of Computer Science 333 Stockholm 334 Sweden 336 Email: bengta@sics.se