[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Individual Submission                                          B. Ohlman
Internet-Draft                                                  Ericsson
Intended status: Informational                             O. Strandberg
Expires: April 28, 2011                           Nokia Siemens Networks
                                                            C. Dannewitz
                                                 University of Paderborn
                                                             A. Lindgren
                                                                    SICS
                                                             R. Maglione
                                                          Telecom Italia
                                                              B. Ahlgren
                                                                    SICS
                                                             D. Kutscher
                                                                     NEC
                                                        October 25, 2010


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

Abstract

   The DECoupled Application Data Enroute (DECADE) working group is
   specifying standardized interfaces for accessing in-network storage
   from applications to store, retrieve and manage data.  The main
   objective is to provide a framework that is useful to P2P
   applications, without excluding other, possibly related applications
   that can benefit from accessing in-network storage.  This memo
   presents Internet TV as a specific application scenario where access
   to in-netork storage would be required and lists a set of concrete
   requirements that should be considered for the DECADE architecture
   and protocol specifications.

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/.



Ohlman, et al.           Expires April 28, 2011                 [Page 1]


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


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   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 April 28, 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 April 28, 2011                 [Page 2]


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


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Internet TV Scenario  . . . . . . . . . . . . . . . . . . . . . 5
     2.1.  Detailed Scenario Description . . . . . . . . . . . . . . . 5
     2.2.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   3.  Specific requirements . . . . . . . . . . . . . . . . . . . . . 6
     3.1.  Unique Naming of Information Objects  . . . . . . . . . . . 6
       3.1.1.  Requirement . . . . . . . . . . . . . . . . . . . . . . 6
       3.1.2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . 7
       3.1.3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . 7
     3.2.  Access to Information Objects . . . . . . . . . . . . . . . 7
       3.2.1.  Requirement . . . . . . . . . . . . . . . . . . . . . . 7
       3.2.2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . 7
       3.2.3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . 7
     3.3.  Real-time Support . . . . . . . . . . . . . . . . . . . . . 7
       3.3.1.  Requirement . . . . . . . . . . . . . . . . . . . . . . 7
       3.3.2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . 7
       3.3.3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . 8
     3.4.  Discovery service for DECADE in-network storage . . . . . . 8
       3.4.1.  Requirement . . . . . . . . . . . . . . . . . . . . . . 8
       3.4.2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . 8
       3.4.3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . 8
     3.5.  Multiple active DECADE Storage Servers  . . . . . . . . . . 8
       3.5.1.  Requirement . . . . . . . . . . . . . . . . . . . . . . 8
       3.5.2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . 8
       3.5.3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . 8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9
   7.  Informative References  . . . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



















Ohlman, et al.           Expires April 28, 2011                 [Page 3]


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


1.  Introduction

   The DECADE approach to access to in-network storage through
   standardized interfaces has been motivated by P2P application
   scenarios where it can be beneficial to refer peers to in-network
   storage system in a convenient network-topological location in order
   to enhance data exchange for a given P2P application.

   One specific example would be a P2P application instance in a home
   network connected via an ADSL access network.  In a traditional P2P
   approach, this application instance would download chunks from other
   peers and serve chunks to other peers in parallel.  With an
   asymmetric uplink, the application instance (and other hosts on the
   home network) are likely to experience uplink congestion, if the
   application instance is selected by a substantial number of peers and
   has to serve data to them.  In situations with prevalent asymmetric
   access links, the P2P session (all peer application instances) would
   also be limited in the achievable downlink speed because the
   aggregate uplink bandwidth is not sufficient.

   DECADE in-network storage servers are expected to be helpful in such
   scenarios, because peers could be referred to appropriate storage
   servers for downloading some content, thereby offloading traffic from
   the capacity-limited access uplinks.

   Such storage servers are expected to provide interfaces for storing,
   retrieving, and managing data.  The general concept is that, in a
   distributed P2P application, some instance would upload data to a
   storage server and then refer other instances, such as P2P peers, to
   that data, for instance by passing a certain URI.  In addition, there
   could be interactions for allocating capacity on servers for certain
   applications, for deleting data etc.

   This document argues that, while such a system would be very useful
   for P2P applications, there are others, related applications that
   could benefit from in-network storage in just the same way.  Though
   only applications that does not lead to a completely new set of
   requirements should be taken into account.  This document argues that
   it should be possible to extend the DECADE work to include certain
   other applications without increasing the overall complexity of the
   solution.

   Specifically, this document describes the in-network-storage aspects
   of Internet TV -- an important application today, that can
   significantly benefit from in-network-caching.  We argue that it
   seems negligent to exclude Internet TV from leveraging DECADE in-
   network-storage and describe specific use cases for accessing in-
   network-storage in such a scenario.  Moreover, we present a set of



Ohlman, et al.           Expires April 28, 2011                 [Page 4]


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


   requirements that should be met by the DECADE architecture design in
   order guarantee its applicability to such applications.  We propose
   that these requirements be added to the DECADE requirements
   specification.

   In this memo, we align the requirement description to the layout used
   in [I-D.gu-decade-reqs].  Section 2 describes the Internet TV
   scenario, and Section 3 presents corresponding requirements that
   should be considered to ensure a broad enough applicability of the
   DECADE framework.


2.  Internet TV Scenario

   Internet TV is a general term to refer to different kinds of systems
   or applications where video is delivered to (mostly) home network
   devices for immediate rendering or storing.  In this memo, we refer
   to the distribution of video content, mainly focusing on Video-on-
   Demand (VoD) services and user-generated content.

   VoD services are commonly widespread in many service providers'
   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 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, also for mobile
   users, can be improved.

2.1.  Detailed Scenario Description

   A well-known issue with Internet TV applications such as YouTube is
   the flash crowd problem.  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.  This can be extra beneficial for services with
   real-time (or near real-time) components as traditional pre-caching
   solutions can be difficult to use then.

   A particular interesting Internet TV variant is "hybrid Internet TV"
   based on an Internet TV distribution service that is a hybrid between
   traditional CDN and a P2P service.  Such a service would distribute
   content from central servers, make use of CDN caches on the way and
   finally use the end hosts/STB as caches for the P2P part of the



Ohlman, et al.           Expires April 28, 2011                 [Page 5]


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


   application.

   If only the P2P application in the host/STB can store content in the
   DECADE storage, the content first has to be downloaded from the
   Internet TV server/CDN cache over the access link to the host/STB and
   then uploaded, over the same access link, to the DECADE storage
   before any peer in the P2P part of the application can access it from
   the DECADE storage (instead of downloading it from the client).

   To avoid this, it should be possible for the DECADE storage to
   'cache' the content when the first download to the host/STB is done.
   That would mean the content never have to travel over the capacity-
   limited uplink.  For this to be feasible, one requirement is that the
   Internet TV service can prompt the DECADE storage that certain
   content should be cached on its way to the host.  Having such
   functionality, that allows a host to get content from the DECADE
   storage of neighboring host rather than from a central server, would
   of course also offload the core network in the same way a traditional
   CDN does.

2.2.  Summary

   The DECADE architecture and protocol specifications should take the
   hybrid Internet TV scenario into account to ensure a reasonable level
   of generality of the DECADE in-network storage.  While P2P-specific
   requirements should be considered, DECADE should not be unnecessarily
   limited to it.

   Specifically, dissemination applications of streaming type (some with
   real-time or close to real-time requirements) should be supported by
   DECADE 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.


3.  Specific requirements

3.1.  Unique Naming of Information Objects

3.1.1.  Requirement

   When a DECADE client in a certain application context stores an
   information object in DECADE storage servers, the object MUST be
   addressable by a unique name across different application contexts.






Ohlman, et al.           Expires April 28, 2011                 [Page 6]


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


3.1.2.  Rationale

   There is a need for unique naming to enable different application
   instances to refer to information objects using a name (that may have
   been provided to them by another DECADE client).  Such unique naming
   is essential for efficient cache handling and can serve for de-
   duplication.

3.1.3.  Discussion

   Unique naming can be achieved in different ways.  Names can assigned
   from some (structured) names, for instance by URIs.  Names can also
   be generated, for instance by calculating hashes of the object's
   content.

   The detailed syntax and semantics of DECADE names (and the actual
   standardization requirements) are for further study.

3.2.  Access to Information Objects

3.2.1.  Requirement

   It MUST be possible to access data stored on DECADE storage servers
   as complete information objects, such as a named video file.

3.2.2.  Rationale

   In a video-on-demand caching use case, the client application should
   be enabled to retrieve the complete object in one transaction and
   should not be required to download individual chunks.

3.2.3.  Discussion

   This does not necessarily impose implications on the way that the
   storage servers stores the object.

3.3.  Real-time Support

3.3.1.  Requirement

   The DECADE storage service MUST support real-time applications in a
   way that a resource that is being uploaded is already available for
   download.

3.3.2.  Rationale

   For larger objects or chunks, it is not acceptable if a DECADE client
   has to upload the complete resource first, before other clients can



Ohlman, et al.           Expires April 28, 2011                 [Page 7]


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


   start downloading it.

3.3.3.  Discussion

   This requirement should also be important for P2P live streaming.

3.4.  Discovery service for DECADE in-network storage

3.4.1.  Requirement

   When a DECADE client attach to a DECADE enabled network there SHOULD
   be a discovery service that can tell a DECADE client where in-network
   storage servers can be found.

3.4.2.  Rationale

   To minimize manual configuration of the DECADE clients, a discovery
   service, similar to DHCP , should be provided in the DECADE enabled
   network.

3.4.3.  Discussion

   In particular, this simplifies the administration of the DECADE in-
   network storage for a user that roams to a visited network.

3.5.  Multiple active DECADE Storage Servers

3.5.1.  Requirement

   A DECADE client SHOULD be able to use multiple in-network storage
   servers at the same time.

3.5.2.  Rationale

   One example of when this is needed is when a user/client roams to
   another network, then it is reasonable to assume that the currently
   used in-network storage remains active for a certain time not to
   disrupt ongoing communication sessions at the same time as another
   in-network storage might immediately be needed in the new network.

3.5.3.  Discussion

   A user of DECADE in-network storage who 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.
   Usage that could result in such inefficiencies is communication with
   other users locally in the same network, for example as part of a



Ohlman, et al.           Expires April 28, 2011                 [Page 8]


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


   small meeting or large event (fair, sports event, etc).

   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.  Acknowledgments

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


7.  Informative References

   [I-D.gu-decade-reqs]
              Yingjie, G., Bryan, D., Yang, Y., and R. Alimi, "DECADE
              Requirements", draft-gu-decade-reqs-05 (work in progress),
              July 2010.

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


Authors' Addresses

   Borje Ohlman
   Ericsson
   Stockholm
   Sweden

   Email: Borje.Ohlman@ericsson.com





Ohlman, et al.           Expires April 28, 2011                 [Page 9]


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


   Ove Strandberg
   Nokia Siemens Networks
   Linnoitustie 6
   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


   Bengt Ahlgren
   Swedish Institute of Computer Science
   Stockholm
   Sweden

   Email: bengta@sics.se












Ohlman, et al.           Expires April 28, 2011                [Page 10]


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


   Dirk Kutscher
   NEC Laboratories Europe
   Kurfuersten-Anlage 36
   Heidelberg
   Germany

   Email: kutscher@neclab.eu












































Ohlman, et al.           Expires April 28, 2011                [Page 11]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/