Internet DRAFT - draft-marocco-alto-next
draft-marocco-alto-next
Internet Engineering Task Force E. Marocco
Internet-Draft Telecom Italia
Intended status: Informational V. Gurbani
Expires: July 23, 2012 Bell Laboratories,
Alcatel-Lucent
January 20, 2012
Extending the Application-Layer Traffic Optimization (ALTO) Protocol
draft-marocco-alto-next-00
Abstract
The Application-Layer Traffic Optimization (ALTO) protocol is
designed to allow entities with knowledge about the network
infrastructure to export such information to applications that need
to choose one or more endpoints to connect to among large sets of
logically equivalent ones. The primary use case for the ALTO
protocol was peer-to-peer applications for file sharing, video
streaming and realtime communications, usually running on end-user
devices. However, a number of other applications executing in more
controlled environments may also benefit from the information that
can be exported through the ALTO protocol. The use cases that have
received significant attention include Content Delivery Networks
(CDNs), distributed applications running in large datacenters, as
well as systems made of inter-communicating ALTO servers.
To apply ALTO to these new use cases, this document aims to foster a
discussion to determine if, and how, the ALTO protocol could be
extended to provide a simple yet useful view of a computational
environment that goes beyond the static (or near static) network
topology and cost map information.
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
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Marocco & Gurbani Expires July 23, 2012 [Page 1]
Internet-Draft Extending ALTO January 2012
This Internet-Draft will expire on July 23, 2012.
Copyright Notice
Copyright (c) 2012 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.
Marocco & Gurbani Expires July 23, 2012 [Page 2]
Internet-Draft Extending ALTO January 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Content Delivery Networks (CDNs) . . . . . . . . . . . . . 5
2.2. Virtualized Applications in Datacenters . . . . . . . . . 6
2.3. ALTO Server-to-server Communications . . . . . . . . . . . 6
3. New Protocol Features . . . . . . . . . . . . . . . . . . . . 6
3.1. Server-initiated Notifications . . . . . . . . . . . . . . 7
3.2. ALTO Information Extensions . . . . . . . . . . . . . . . 8
3.2.1. Bandwidth Availability Between Hosts . . . . . . . . . 9
3.2.2. Resource Availability on Hosts . . . . . . . . . . . . 9
3.2.3. Content Availability on Hosts . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Normative References . . . . . . . . . . . . . . . . . . . 10
5.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Marocco & Gurbani Expires July 23, 2012 [Page 3]
Internet-Draft Extending ALTO January 2012
1. Introduction
The Application-Layer Traffic Optimization (ALTO) protocol is
designed to allow entities with knowledge about the network
infrastructure to export such information to applications that need
to choose one or more endpoints to connect to among large sets of
logically equivalent ones. The primary use case for the ALTO
protocol was peer-to-peer applications for file sharing, video
streaming and realtime communications, usually running on end-user
devices. However, a number of other applications executing in more
controlled environments may also benefit from the information that
can be exported through the ALTO protocol. The use cases that have
received significant attention include Content Delivery Networks
(CDNs), distributed applications running in large datacenters, as
well as systems made of inter-communicating ALTO servers.
Such applications require information about the underlying
infrastructure that goes beyond network topology and associated
costs. We believe that the ALTO protocol can be easily extended to
provide this information.
The basic idea is to use the ALTO protocol to present a simplified
view of a computational environment, aggregating with some level of
abstraction and approximation information that at a fine-grained
level may be conveyed by protocols like OSPF, ISIS, BGP, SNMP, ECN,
and ConEx.
To provide such kind of information the ALTO protocol need to be
extended on several axes:
o a means for providing incremental updates to optimize for
frequently changing information;
o a means for providing integrity protection for the information
provided by an ALTO server, in order to enable information
redistribution;
o a server-initiated notification mechanism, for promptly informing
applications of status changes;
o different types of information, not only related to network costs,
such as:
* network link load;
* server load;
Marocco & Gurbani Expires July 23, 2012 [Page 4]
Internet-Draft Extending ALTO January 2012
* availability of resources such as storage memory, content and
installed applications.
Detail-level and timescale of the additional information that can be
provided are an open topic of discussion. If on the one hand
applications may not take any advantage of too coarse-grained
infromation, on the other hand ALTO protocol extensions cannot
satisfy all the requirements of the mechanisms that today make full
use of such low level information and therefore must not be intended
in any way as a replacement for them. The goal of this document is
to frame the discussion of what could be reasonable compromises for
exporting information of the underlying network and computational
infrastructure to applications that need to make best use of it.
1.1. 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 RFC 2119 [RFC2119].
2. Use Cases
2.1. Content Delivery Networks (CDNs)
CDNs consist of systems of caching servers that cooperate in the
distribution of frequently requested content. When a client wants to
access some content, the request is directed by the CDN routing logic
to the most appropriate caching server. The criteria for selecting
the most appropriate server can be arbitrary complex and depend of
information such as:
o network distance betwen the querying client and the caching
server;
o load of the caching server, e.g. in terms of number of concurrent
requests or available serving capacity measured over a recent
timeframe;
o content availability;
o storage capacity availablity, for deciding whether to replicate
some content on servers that do not have it yet.
Marocco & Gurbani Expires July 23, 2012 [Page 5]
Internet-Draft Extending ALTO January 2012
2.2. Virtualized Applications in Datacenters
Applications running on virtual servers in large datacenters require
dynamic allocation of resources such as computation power, storage
capacity and network bandwidth. Datacenter management logic allocate
the resources of physycal servers to such applications based on
information such as:
o resource availability on the physycal servers;
o application code and configurations availability on the physycal
servers;
o network connectivity quality (i.e. delay and expected throughput)
between the physycal servers the virtual server is already running
on, and the new physycal servers the additional resources may be
allocated from.
2.3. ALTO Server-to-server Communications
ALTO servers can improve the guidance they provide by aggregating
information distributed by other servers (see
[I-D.medved-alto-svr-apis] and
[I-D.dulinski-alto-inter-problem-statement]). In such scenarios, for
the model to be effective, at any point in time all servers need to
have a fresh version of the information distributed by the servers
they are communicating with, regardless of the type of information
distributed. However, the frequency of changes increases with the
number of communicating servers, and the faster the information
changes, the less the pull-based approach of the base ALTO protocol
[I-D.ietf-alto-protocol] is suitable for maintaining an updated
representation of the environment status.
3. New Protocol Features
This section discusses some extensions to the ALTO protocol that can
be used to cover the use cases described in Section 2. Such
extensions include:
o incremental updates for the network and cost maps defined in the
base ALTO protocol [I-D.ietf-alto-protocol], for the CDN,
datacenter and server-to-server use cases, to enable efficient
transmission of status changes;
o integrity protection, for the server-to-server use case, to enable
servers assert the authenticity of data re-distributed by other
servers;
Marocco & Gurbani Expires July 23, 2012 [Page 6]
Internet-Draft Extending ALTO January 2012
o a mechanism for server-initiated notifications, for the CDN,
datacenters and server-to-server use cases, to enable a fast
propagation of the status changes;
o new types of information for the ALTO protocol, for the CDN and
datacenters use cases, to provide a representation of the
computational environment that goes beyond the network topology.
Incremental updates and integrity protection are easily defined on
the basis of existing (ongoing) work, namely [I-D.pbryan-json-patch]
and [I-D.jones-json-web-signature]. The remainder of this section
discusses the other, perhaps more controversial extensions.
3.1. Server-initiated Notifications
The base ALTO protocol [I-D.ietf-alto-protocol] defines a JSON-based
syntax to be conveyed statelessly over HTTP. Such a lightweight
approach has several advantages and is considered most appropriate
for the use case of peer-to-peer applications, where the information
is likely to be retrieved and consumed by huge numbers of clients.
However, in more controlled environment, the same information, with
the same or an equivalent syntax, can also be conveyed by different
protocols, such as XMPP, SIP, or by any protocol with publish/
subscribe capabilities that would allow servers to send updates to
subscribed clients.
Marocco & Gurbani Expires July 23, 2012 [Page 7]
Internet-Draft Extending ALTO January 2012
As an example, if an ALTO service provider wanted to make cost
maps available also through XMPP (assuming some kind of
specification for ALTO-over-XMPP exists), it could simply
advertize the proper URI in the information resource directory
along with the basic HTTP one:
{
"resources" : [
{
"uri" : "http://alto.example.com/serverinfo",
"media-types" : [ "application/alto-serverinfo+json" ]
}, {
"uri" : "http://alto.example.com/networkmap",
"media-types" : [ "application/alto-networkmap+json" ]
}, {
"uri" : "http://alto.example.com/costmap/num/routingcost",
"media-types" : [ "application/alto-costmap+json" ],
"additional-uris" : [ "xmpp:routingcost@alto.example.com" ],
"capabilities" : {
"cost-modes" : [ "numerical" ],
"cost-types" : [ "routingcost" ]
}
}, {
"uri" : "http://alto.example.com/costmap/num/hopcount",
"media-types" : [ "application/alto-costmap+json" ],
"additional-uris" : [ "xmpp:hopcount@alto.example.com" ],
"capabilities" : {
"cost-modes" : [ "numerical" ],
"cost-types" : [ "hopcount" ]
}
},
.
.
.
]
}
3.2. ALTO Information Extensions
The base ALTO protocol [I-D.ietf-alto-protocol] has been designed to
be easily extended, in terms of both endpoint properties and path
cost types. The reminder of this section discusses the types of
information that are required by the use cases described in Section 2
and that would allow an ALTO servers to expose an abstract
representation of a computational environment beyond the simple
network topology.
Marocco & Gurbani Expires July 23, 2012 [Page 8]
Internet-Draft Extending ALTO January 2012
3.2.1. Bandwidth Availability Between Hosts
Bandwidth availability is a kind of information that changes
instantaneously and strictly depends on applications behavior. For
such (and other) reasons, conveying it for congestion control other
than in-band within the data flows may result useless at best, if not
the cause of detrimental feedback loops.
However, some notion of link bandwidth availability averaged over a
reasonabe timeframe may be effectively used by CDN or datacenter
applications to select well-connected pairs or groups of hosts that
have to perform bandwidth-demanding tasks.
Information about bandwidth availability can be defined for encoding
in the ALTO protocol as a new path cost type.
3.2.2. Resource Availability on Hosts
Information about storage and computational capacity availability
averaged over a reasonable timeframe may be effectively used by CDN
and datacenter applications as one of the criteria for selecting
hosts for serving content or performing tasks.
Information about resource availability can be defined for encoding
in the ALTO protocol as a new endpoint property.
3.2.3. Content Availability on Hosts
Information about content availability can be expressed as lists of
URIs (e.g. for identifying stored files in CDN caching servers), URNs
or other kinds of identifiers (e.g. for identifying installed
applications on physycal servers in a datacenter).
Information about content availability can be defined for encoding in
the ALTO protocol as a new endpoint property.
4. Security Considerations
The information types discussed in this document are likely to be
privacy critical in many environment and therefore must be protected,
restricting or controlling access to the servers that export them.
Server initiated notification requires more resources than the
stateless retrivial model adopted by the base ALTO protocol
[I-D.ietf-alto-protocol] and is more thus more vulnerable to denial
of service attacks.
Marocco & Gurbani Expires July 23, 2012 [Page 9]
Internet-Draft Extending ALTO January 2012
Access control mechanisms, including HTTP's, may be valid options for
addressing the security issues related to both privacy critical
information types and resource-consuming server notifications.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informative References
[I-D.dulinski-alto-inter-problem-statement]
Dulinski, Z., Wydrych, P., and R. Stankiewicz, "Inter-ALTO
Communication Problem Statement",
draft-dulinski-alto-inter-problem-statement-01 (work in
progress), July 2011.
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-10 (work in progress),
October 2011.
[I-D.jones-json-web-signature]
Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer,
J., Sakimura, N., and P. Tarjan, "JSON Web Signature
(JWS)", draft-jones-json-web-signature-04 (work in
progress), December 2011.
[I-D.medved-alto-svr-apis]
Medved, J., Ward, D., Peterson, J., Woundy, R., and D.
McDysan, "ALTO Network-Server and Server-Server APIs",
draft-medved-alto-svr-apis-00 (work in progress),
March 2011.
[I-D.pbryan-json-patch]
Bryan, P., "JSON Patch", draft-pbryan-json-patch-04 (work
in progress), December 2011.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
Marocco & Gurbani Expires July 23, 2012 [Page 10]
Internet-Draft Extending ALTO January 2012
Authors' Addresses
Enrico Marocco
Telecom Italia
Via Reiss Romoli, 274
Torino, 10148
Italy
Phone:
Email: enrico.marocco@telecomitalia.it
Vijay K. Gurbani
Bell Laboratories, Alcatel-Lucent
Email: vkg@bell-labs.com
Marocco & Gurbani Expires July 23, 2012 [Page 11]
