idnits 2.17.1 draft-ohlman-decade-add-use-cases-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 1, 2010) is 5167 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.gu-decade-reqs' is defined on line 255, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-gu-decade-reqs-02 Summary: 1 error (**), 0 flaws (~~), 4 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: September 2, 2010 Nokia Siemens Networks 6 C. Dannewitz 7 University of Paderborn 8 A. Lindgren 9 Swedish Institute of Computer 10 Science 11 R. Maglione 12 Telecom Italia 13 March 1, 2010 15 Requirements for accessing data in network storage 16 draft-ohlman-decade-add-use-cases-reqs-00 18 Abstract 20 So far, the intended scope of the DECoupled Application Data Enroute 21 (DECADE) working group has mainly been focused on peer-to-peer (P2P) 22 applications. There are however many non-P2P-based application that 23 could also benefit from in-network storage. The target of DECADE 24 should thus specify a protocol that is also suitable for generic 25 applications with certain characteristics and not only P2P 26 applications. This document enumerates a number of requirements that 27 should be considered during the design and implementation of this 28 protocol. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119]. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This Internet-Draft will expire on September 2, 2010. 59 Copyright Notice 61 Copyright (c) 2010 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the BSD License. 74 This document may contain material from IETF Documents or IETF 75 Contributions published or made publicly available before November 76 10, 2008. The person(s) controlling the copyright in some of this 77 material may not have granted the IETF Trust the right to allow 78 modifications of such material outside the IETF Standards Process. 79 Without obtaining an adequate license from the person(s) controlling 80 the copyright in such materials, this document may not be modified 81 outside the IETF Standards Process, and derivative works of it may 82 not be created outside the IETF Standards Process, except to format 83 it for publication as an RFC or to translate it into languages other 84 than English. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 89 2. General principles . . . . . . . . . . . . . . . . . . . . . . 4 90 2.1. Application-agnostic . . . . . . . . . . . . . . . . . . . 5 91 2.1.1. Requirement . . . . . . . . . . . . . . . . . . . . . . 5 92 2.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 5 93 2.2. Data reuse . . . . . . . . . . . . . . . . . . . . . . . . 5 94 2.2.1. Requirement . . . . . . . . . . . . . . . . . . . . . . 5 95 2.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 5 96 3. Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . 6 97 3.1. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 6 98 3.1.1. Requirement . . . . . . . . . . . . . . . . . . . . . . 6 99 3.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . 6 100 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 101 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 102 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 103 7. Informative References . . . . . . . . . . . . . . . . . . . . 7 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 106 1. Introduction 108 This draft suggests that DECADE should provide an application 109 agnostic network storage mechanism, that is not only focused on P2P 110 specific mechanisms. To ensure this we would like to make sure the 111 scope of DECADE includes at least one use case besides the P2P use 112 case. This second use case could for example be IPTV, but other 113 alternative proposals that can represent the main characteristics of 114 popular dissemination applications could also be used. This draft 115 also want to make sure that requirements on the possibility of data 116 reuse of cached copies in the network and of support for mobility are 117 included in the WG charter. Thus the goal of this draft is to 118 address some generic requirements that should be supported by in- 119 network storage, both from an application and a use case situation 120 point of view. 122 This draft recogizes that DECADE have complementary requirements in 123 the updated draft; I-D.draft-gu-decade-reqs-02 and aligns the layout 124 accordingly. 126 This document enumerates and explains the rationale behind additional 127 requirements that should be considered in the specification of a 128 protocol for DECADE. 130 2. General principles 132 Other applications than P2P should be supported by DECADE, especially 133 dissemination applications of streaming type (some with real-time or 134 close to real-time requirements) as they can cause significant load 135 on the network. The network load could be reduced significantly for 136 these types of applications if copies stored locally in the network 137 could be used instead of always fetching data from the source. 139 A scenario that we are considering of a particular interest in this 140 respect is represented by the IPTV use case. By IPTV we are 141 referring here to the distribution of video content, mainly focusing 142 on Video-on-Demand (VoD) services and user-generated contents. VoD 143 services are commonly widespread in many Service Provider's networks. 144 This scenario is characterized by the need to support an efficient 145 large-scale distribution of video, possibly with a fairly high degree 146 of replicated contents, to a multiplicity of fixed and mobile users. 147 By supporting this application with the DECADE protocols, video 148 content can be retrieved from the in-network storage, achieving a 149 number of benefits. The originating servers can be relieved from 150 most of the load, since popular content will be automatically 151 available in the in-network storage, closer to the users. Improved 152 network efficiency will be achieved, reducing the traffic load in the 153 upstream network segments. Moreover user experience, including 154 mobile ones, can also be improved. 156 2.1. Application-agnostic 158 2.1.1. Requirement 160 The specification of DECADE SHOULD strive to make the DECADE in- 161 network storage application-agnostic. As a verification of this 162 effort DECADE SHOULD be specified in such a way that it can address 163 at least one other application type, besides P2P applications. 165 2.1.2. Rationale 167 The currently proposed DECADE charter mainly addresses P2P 168 applications. However, there are other applications that also have 169 large footprint in the network load and could benefit from the work 170 done in DECADE. There is no need to address the requirements of all 171 types of applications but it should be ensured that DECADE implements 172 generic properties that are reasonably application agnostic. In 173 order to make sure that this is the case, it is proposed that at 174 least one more application type is taken into account. An example of 175 such an application could be large-scale video distribution such as 176 IPTV, YouTube, etc. A well-known issue with these applications is 177 the problem with flash crowds. That is also an example of a problem 178 which could be significantly eased if in-network storage is used to 179 provide users with locally available copies rather than all 180 requesting the data from the source (as outlined below in 181 Section 2.2). This can be extra beneficial for services with 182 realtime (or near realtime) components as traditional pre-caching 183 solutions can be difficult to use then. 185 2.2. Data reuse 187 2.2.1. Requirement 189 When certain content is popular and used by many users, the network 190 part of DECADE SHOULD be able to store only one (or any limited 191 number) copy of that data. The same data can then be used to serve 192 requests from multiple DECADE users. 194 2.2.2. Rationale 196 For an application like IPTV it is clear that multiple users will 197 request the same content, and thus wish to store multiple copies of 198 the same content in the in-network storage using DECADE. For these, 199 often very large, data objects it is clear that significant resources 200 can be saved in the network if a limited number of copies can be 201 stored in, for the network, strategic locations such that the usage 202 of storage and transmission resources are optimized. By only storing 203 a single copy of the data at each node, the storage requirements can 204 be greatly reduced. It has also been shown that there are strong 205 locality characteristics among requests for this type of content as 206 it's popularity often spreads through social networks or through a 207 geographic region [yoneki_09][gill_07]. This indicates that the 208 potential savings are very large. Well established use of web 209 proxies also indicates that data reuse can be a potential key 210 feature. 212 3. Data Access 214 3.1. Mobility 216 3.1.1. Requirement 218 DECADE SHOULD have the ability to support mobility of terminals/ 219 users/applications by allowing the use of a data object that is 220 available near a new location when moving. DECADE COULD also provide 221 nomadic network storage. 223 3.1.2. Rationale 225 A lot of today's terminals are mobile, e.g. laptops and smartphones. 226 If locally found copies of data can be delivered to the DECADE user 227 the network can avoid a lot of cross network traffic that would be 228 needed to retrieve the data object from the home storage. If no 229 local copies can be found it can, under certain circumstances be 230 beneficial if the in-network storage of a DECADE user can move with 231 them (or become temporarily duplicated, depending on the expected 232 mobility characteristics) in order to avoid tunneling back to the 233 home storage. This can both improve performance for the mobile users 234 as data does not have to be fetched over a long-distance link, but 235 can also reduce costs for operators by reducing the traffic load in 236 their access networks. 238 4. IANA Considerations 240 This document has no requests to IANA. 242 5. Security Considerations 244 The re-use of copies in the network part of DECADE will require that 245 appropriate access control mechanisms are designed. 247 6. Acknowledgements 249 We would like to thank all persons participating in the Network of 250 Information work package in the EU FP7 project 4WARD for 251 contributions and feedback to this document. 253 7. Informative References 255 [I-D.gu-decade-reqs] 256 Yingjie, G., Yongchao, S., Yang, Y., and R. Alimi, "DECADE 257 Requirements", draft-gu-decade-reqs-02 (work in progress), 258 December 2009. 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [gill_07] Gill, P., Arlitt, M., Li, Z., and A. Mahanti, "Youtube 264 traffic characterization: a view from the edge", 265 Proceedings of the 7th ACM SIGCOMM conference on Internet 266 measurement , 2007. 268 [yoneki_09] 269 Yoneki, E., Sastry, N., and J. Crowcroft, "Buzztraq: 270 predicting geographical access patterns of social cascades 271 using social networks", Proceedings of the Second ACM 272 EuroSys Workshop on Social Network Systems , 2009. 274 Authors' Addresses 276 Borje Ohlman 277 Ericsson 278 Stockholm 279 Sweden 281 Email: Borje.Ohlman@ericsson.com 283 Ove Strandberg 284 Nokia Siemens Networks 285 Espoo 286 Finland 288 Email: ove.strandberg@nsn.com 289 Christian Dannewitz 290 University of Paderborn 291 Paderborn 292 Germany 294 Email: cdannewitz@upb.de 296 Anders Lindgren 297 Swedish Institute of Computer Science 298 Stockholm 299 Sweden 301 Email: andersl@sics.se 303 Roberta Maglione 304 Telecom Italia 305 Turin 306 Italy 308 Email: roberta.maglione@telecomitalia.it