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]