[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Individual Submission                                          B. Ohlman
Internet-Draft                                                  Ericsson
Intended status: Informational                             O. Strandberg
Expires: January 10, 2011                         Nokia Siemens Networks
                                                            C. Dannewitz
                                                 University of Paderborn
                                                             A. Lindgren
                                                                    SICS
                                                             R. Maglione
                                                          Telecom Italia
                                                              B. Ahlgren
                                                                    SICS
                                                            July 9, 2010


           Requirements for accessing data in network storage
               draft-ohlman-decade-add-use-cases-reqs-01

Abstract

   So far, the intended scope of the DECoupled Application Data Enroute
   (DECADE) working group has mainly been focused on peer-to-peer (P2P)
   applications.  There are however many non-P2P-based applications that
   could also benefit from in-network storage for caching content.  The
   target of DECADE should thus be to specify a mechanism that is also
   suitable for generic applications with certain characteristics and
   not only P2P applications.  This document enumerates a number of
   requirements that should be considered during the design and
   implementation of this mechanism.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Ohlman, et al.          Expires January 10, 2011                [Page 1]


Internet-Draft          decade-add-use-cases-reqs              July 2010


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 10, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.




















Ohlman, et al.          Expires January 10, 2011                [Page 2]


Internet-Draft          decade-add-use-cases-reqs              July 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  General principles  . . . . . . . . . . . . . . . . . . . . . . 4
     2.1.  Application-agnostic  . . . . . . . . . . . . . . . . . . . 5
       2.1.1.  Requirement . . . . . . . . . . . . . . . . . . . . . . 5
       2.1.2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . 5
     2.2.  Data reuse  . . . . . . . . . . . . . . . . . . . . . . . . 5
       2.2.1.  Requirement . . . . . . . . . . . . . . . . . . . . . . 5
       2.2.2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . 5
       2.2.3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . 6
   3.  Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.1.  Roaming users . . . . . . . . . . . . . . . . . . . . . . . 6
       3.1.1.  Requirement . . . . . . . . . . . . . . . . . . . . . . 6
       3.1.2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . 6
       3.1.3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . 7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Informative References  . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8






























Ohlman, et al.          Expires January 10, 2011                [Page 3]


Internet-Draft          decade-add-use-cases-reqs              July 2010


1.  Introduction

   This draft suggests that DECADE should provide an application
   agnostic network storage mechanism that not only supports P2P
   applications.  To ensure this we suggest to extend the scope of
   DECADE to include at least one use case besides the P2P use case.
   This second use case could for example be IPTV, but other alternative
   proposals that can represent the main characteristics of popular
   dissemination applications could also be used.  This draft also wants
   to make sure that requirements on the possibility of data reuse of
   cached copies in the network and of support for mobility are included
   in the WG charter.  Thus the goal of this draft is to address some
   generic requirements that should be supported by in-network storage,
   both from an application and a use case situation point of view.

   This draft recognizes that DECADE have complementary requirements in
   the updated draft; [I-D.gu-decade-reqs] and aligns the layout
   accordingly.

   This document enumerates and explains the rationale behind additional
   requirements that should be considered in the specification of a
   protocol for DECADE.


2.  General principles

   Other applications than P2P should be supported by DECADE, especially
   dissemination applications of streaming type (some with real-time or
   close to real-time requirements) as they can cause significant load
   on the network.  The network load could be reduced significantly for
   these types of applications if copies stored locally in the network
   could be used instead of always fetching data from the source.

   A scenario that we are considering of a particular interest in this
   respect is represented by the IPTV use case.  By IPTV we are
   referring here to the distribution of video content, mainly focusing
   on Video-on-Demand (VoD) services and user-generated contents.  VoD
   services are commonly widespread in many Service Provider's networks.
   This scenario is characterized by the need to support an efficient
   large-scale distribution of video, possibly with a fairly high degree
   of replicated contents, to a multiplicity of fixed and mobile users.
   By supporting this application with the DECADE protocols, video
   content can be retrieved from the in-network storage, achieving a
   number of benefits.  The originating servers can be relieved from
   most of the load, since popular content will be automatically
   available in the in-network storage, closer to the users.  Improved
   network efficiency will be achieved, reducing the traffic load in the
   upstream network segments.  Moreover user experience, including



Ohlman, et al.          Expires January 10, 2011                [Page 4]


Internet-Draft          decade-add-use-cases-reqs              July 2010


   mobile ones, can also be improved.

2.1.  Application-agnostic

2.1.1.  Requirement

   The specification of DECADE SHOULD strive to make the DECADE in-
   network storage application-agnostic.  As a verification of this
   effort DECADE SHOULD be specified in such a way that it can address
   at least one other application type, besides P2P applications.

2.1.2.  Rationale

   The currently proposed DECADE charter mainly addresses P2P
   applications.  However, there are other applications that also have
   large footprint in the network load and could benefit from the work
   done in DECADE.  There is no need to address the requirements of all
   types of applications but it should be ensured that DECADE implements
   generic properties that are reasonably application agnostic.  In
   order to make sure that this is the case, it is proposed that at
   least one more application type is taken into account.  An example of
   such an application could be large-scale video distribution such as
   IPTV, YouTube, etc.  A well-known issue with these applications is
   the problem with flash crowds.  That is also an example of a problem
   which could be significantly eased if in-network storage is used to
   provide users with locally available copies rather than all
   requesting the data from the source (as outlined below in
   Section 2.2).  This can be extra beneficial for services with
   realtime (or near realtime) components as traditional pre-caching
   solutions can be difficult to use then.

2.2.  Data reuse

2.2.1.  Requirement

   When certain content is popular and used by many users, the network
   part of DECADE SHOULD be able to store only one (or any limited
   number) copy of that data.  The same data can then be used to serve
   requests from multiple DECADE users.

2.2.2.  Rationale

   For an application like IPTV it is clear that multiple users will
   request the same content, and thus wish to store multiple copies of
   the same content in the in-network storage using DECADE.  For these,
   often very large, data objects it is clear that significant resources
   can be saved in the network if a limited number of copies can be
   stored in, for the network, strategic locations such that the usage



Ohlman, et al.          Expires January 10, 2011                [Page 5]


Internet-Draft          decade-add-use-cases-reqs              July 2010


   of storage and transmission resources are optimized.  By only storing
   a single copy of the data at each node, the storage requirements can
   be greatly reduced.  It has also been shown that there are strong
   locality characteristics among requests for this type of content as
   it's popularity often spreads through social networks or through a
   geographic region [yoneki_09][gill_07].  This indicates that the
   potential savings are very large.  Well established use of web
   proxies also indicates that data reuse can be a potential key
   feature.

2.2.3.  Discussion

   To make it possible to reuse content in other in-network storage
   locations than the one originally requested there are two important
   requirements that needs to be fulfilled.  The first is that the
   content is named in such a way that copies can be identified in other
   in network storage locations.  To facilitate this content should be
   named in an application independent way.  The second requirement is
   that if you ask for a certain named content you must be able to
   verify that the content returned really is the content associated
   with that name by the original publisher of the content.  This
   property can be achieved by securely binding the name to the content,
   e.g., by including the hash of the content in the name, or with a
   signature, creating self-certifying names.

   In combination with the application-agnostic requirement, the data
   reuse requirement means that it should be possible to make use of the
   same cached data copy through more than one application protocol, for
   example, BitTorrent or HTTP (provided that they are appropriately
   modified, if needed).


3.  Data Access

3.1.  Roaming users

3.1.1.  Requirement

   DECADE SHOULD have the ability to support roaming for terminals/
   users/applications by allowing the use of in-network storage in the
   visited network.

3.1.2.  Rationale

   A user of DECADE in-network storage that roams to a visited network
   could potentially cause very inefficient access to that user's DECADE
   storage.  It is therefore essential that the user is able to acquire
   new DECADE storage which is better located in the visited network.



Ohlman, et al.          Expires January 10, 2011                [Page 6]


Internet-Draft          decade-add-use-cases-reqs              July 2010


   Usage that could result in such inefficiencies is communication with
   other users locally in the same network, for example as part of a
   small meeting or large event (fair, sports event, etc).

3.1.3.  Discussion

   A related issue is the possibility to migrate content from one DECADE
   storage to another when roaming.  We believe that this is covered by
   the requirements on Efficient Transfer (section 3.3) and
   Communication among In-network Storage Elements (section 4.3) of
   [I-D.gu-decade-reqs].


4.  IANA Considerations

   This document has no requests to IANA.


5.  Security Considerations

   The re-use of copies in the network part of DECADE will require that
   appropriate access control mechanisms are designed.


6.  Acknowledgements

   We would like to thank all persons participating in the Network of
   Information work package in the EU FP7 project 4WARD for
   contributions and feedback to this document.


7.  Informative References

   [I-D.gu-decade-reqs]
              Yingjie, G., Yongchao, S., Yang, Y., and R. Alimi, "DECADE
              Requirements", draft-gu-decade-reqs-04 (work in progress),
              March 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [gill_07]  Gill, P., Arlitt, M., Li, Z., and A. Mahanti, "Youtube
              traffic characterization: a view from the edge",
              Proceedings of the 7th ACM SIGCOMM conference on Internet
              measurement , 2007.

   [yoneki_09]
              Yoneki, E., Sastry, N., and J. Crowcroft, "Buzztraq:



Ohlman, et al.          Expires January 10, 2011                [Page 7]


Internet-Draft          decade-add-use-cases-reqs              July 2010


              predicting geographical access patterns of social cascades
              using social networks", Proceedings of the Second ACM
              EuroSys Workshop on Social Network Systems , 2009.


Authors' Addresses

   Borje Ohlman
   Ericsson
   Stockholm
   Sweden

   Email: Borje.Ohlman@ericsson.com


   Ove Strandberg
   Nokia Siemens Networks
   Espoo
   Finland

   Email: ove.strandberg@nsn.com


   Christian Dannewitz
   University of Paderborn
   Paderborn
   Germany

   Email: cdannewitz@upb.de


   Anders Lindgren
   Swedish Institute of Computer Science
   Stockholm
   Sweden

   Email: andersl@sics.se


   Roberta Maglione
   Telecom Italia
   Turin
   Italy

   Email: roberta.maglione@telecomitalia.it






Ohlman, et al.          Expires January 10, 2011                [Page 8]


Internet-Draft          decade-add-use-cases-reqs              July 2010


   Bengt Ahlgren
   Swedish Institute of Computer Science
   Stockholm
   Sweden

   Email: bengta@sics.se













































Ohlman, et al.          Expires January 10, 2011                [Page 9]