ALTO: Application-Layer Traffic Optimization protocol

By on 7 Oct 2020

Category: Tech matters

Tags: , , ,

Blog home

Applications can benefit from network information exposure to make them more flexible in terms of rate adaptation, transmission time and server/path selection among others.

The IETF Application-Layer Traffic Optimization (ALTO) protocol provides network information that applications use for modifying network resource consumption patterns while improving their performance. Published in 2014 (RFC 7285), it specifies an information-publishing interface between an ALTO client and an ALTO server. The ALTO server provides cost maps that allow ALTO clients (applications) to determine preferences among locations in a network, which is represented by a network map.

ALTO has been considered in different use case applications such as peer-to-peer, content distribution networks (CDNs) and data centre applications.

ALTO evolution

Before the ALTO base protocol, the ALTO problem statement and requirements were published in 2009 (RFC 5693) and 2012 (RFC 6708), respectively. More recently, several extensions have been standardized such as deployment considerations (RFC 7971), a multi-cost map to retrieve several cost metrics in a single query/response transaction (RFC 8189), and server discovery (RFC 7286) and cross-domain server discovery (RFC 8686) to identify a topologically nearby ALTO server or ALTO servers outside of a network domain, respectively.

In addition, the current ALTO Working Group (WG) charter (2014) is very close to finalizing its milestones with the following new extensions:

ALTO architecture

ALTO already provides a generic architecture to expose network information for applications to improve their performance. Figure 1 presents a high-level overview of key ALTO mechanisms and abstractions.

A high-level overview of ALTO’s architecture.
Figure 1 — A high-level overview of ALTO’s architecture.

In particular, ALTO introduces generic mechanisms such as:

  • Modularity and flexibility through an explicit division of ALTO network information into (network) information resources.
  • An Information Resource Directory (IRD) providing a list of available information resources in an ALTO server.
  • Information consistency (tag, dependency, multi-info resources) to specify a dependency among different information resources.
  • A generic framework with SSE to perform stream-control, push, and incremental updates of information resources.

Besides, each individual information resource is provided as a RESTful service with very simple, but well-working grammar (essentially JSON grammar).

ALTO also introduces different generic abstractions, including:

  • Entities such as endpoints, aggregation of endpoints (PID), ANEs. A network/property map consists of a set of entities. Each entity supports inheritance and can have capabilities and a set of properties.
  • Paths traversing a network/property map from (some types) of a source entity to a destination entity. Each Path has properties called cost metrics (for example, routingcost, PerfMetrics, MultiCost, CostCalendar). The Endpoint Cost Service (ECS) queries endpoint to endpoint and the cost map queries aggregation to aggregation.
  • Co-flows (path vectors), formed by a  set of paths, with shared ANEs across the co-flows.

Another generic concept introduced is the filter so that information resources can be filtered (for example, filtered network map, filtered cost map).

ALTO re-chartering

Currently, technical discussions are taking place on re-chartering the ALTO WG to support the emerging new uses of ALTO. Following a use-case driven approach, five groups of ALTO service extensions are being sought:

  1. Extensions for cellular networks
  2. Extensions for Multi-access Edge Computing (MEC)
  3. Extensions for huge data
  4. Extensions for inter-domain
  5. ALTO optimizations

Each group includes a list of personal drafts proposing extensions for specific use cases such as cellular information exposure, multi-domain network information exposure, determine service edge, delivering functions over edge computing, predictive throughput for TCP reactive flows, generic query language, in-bound/out-bound network information exposure, HTTP/2/3 support and multi-part message, among others. A shortlist of drafts is expected before the next IETF meeting (IETF 109).

To learn more, please visit the IETF ALTO WG and be sure to read my follow up post on a study I was involved with looking at the design issues associated with ALTO and recommended mechanisms to overcome these.

Danny Alex Lachos Perez is a Ph.D. candidate in the Faculty of Electrical and Computer Engineering at University of Campinas (UNICAMP), Brazil.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please answer the math question * Time limit is exhausted. Please click the refresh button next to the equation below to reload the CAPTCHA (Note: your comment will not be deleted).