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

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 application that could also benefit from in-network storage. The target of DECADE should thus specify a protocol 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 protocol.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Status of this Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 2, 2010.

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

Table of Contents

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

1.  Introduction

This draft suggests that DECADE should provide an application agnostic network storage mechanism, that is not only focused on P2P specific mechanisms. To ensure this we would like to make sure the scope of DECADE includes 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 want 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 recogizes that DECADE have complementary requirements in the updated draft; I-D.draft-gu-decade-reqs-02 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 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 (Data reuse)). 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 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] (Yoneki, E., Sastry, N., and J. Crowcroft, “Buzztraq: predicting geographical access patterns of social cascades using social networks,” 2009.)[gill_07] (Gill, P., Arlitt, M., Li, Z., and A. Mahanti, “Youtube traffic characterization: a view from the edge,” 2007.). 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.

3.  Data Access

3.1.  Mobility

3.1.1.  Requirement

DECADE SHOULD have the ability to support mobility of terminals/users/applications by allowing the use of a data object that is available near a new location when moving. DECADE COULD also provide nomadic network storage.

3.1.2.  Rationale

A lot of today's terminals are mobile, e.g. laptops and smartphones. If locally found copies of data can be delivered to the DECADE user the network can avoid a lot of cross network traffic that would be needed to retrieve the data object from the home storage. If no local copies can be found it can, under certain circumstances be beneficial if the in-network storage of a DECADE user can move with them (or become temporarily duplicated, depending on the expected mobility characteristics) in order to avoid tunneling back to the home storage. This can both improve performance for the mobile users as data does not have to be fetched over a long-distance link, but can also reduce costs for operators by reducing the traffic load in their access networks.

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

Authors' Addresses