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

This Internet-Draft will expire on July 02, 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.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. Use Cases
• 2.1. Content Delivery Networks (CDNs)
• 2.2. Virtualized Applications in Datacenters
• 2.3. ALTO Server-to-server Communications
• 3. New Protocol Features
• 3.1. Server-initiated Notifications
• 3.2. ALTO Information Extensions
• 3.2.1. Bandwidth Availability Between Hosts
• 3.2.2. Resource Availability on Hosts
• 3.2.3. Content Availability on Hosts
• 4. Security Considerations
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Authors' Addresses

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:

• a means for providing incremental updates to optimize for frequently changing information;
• a means for providing integrity protection for the information provided by an ALTO server, in order to enable information redistribution;
• a server-initiated notification mechanism, for promptly informing applications of status changes;
• different types of information, not only related to network costs, such as:
  • network link load;
  • server load;
  • 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:

• network distance betwen the querying client and the caching server;
• load of the caching server, e.g. in terms of number of concurrent requests or available serving capacity measured over a recent timeframe;
• content availability;
• storage capacity availablity, for deciding whether to replicate some content on servers that do not have it yet.

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:

• resource availability on the physycal servers;
• application code and configurations availability on the physycal servers;
• 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:

• 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;
• integrity protection, for the server-to-server use case, to enable servers assert the authenticity of data re-distributed by other servers;
• 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;
• 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.

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.

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.

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

5.2. Informative References

Authors' Addresses