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 Cost Calendar, which provides ALTO cost values where each value corresponds to a specific time interval (currently in the RFC editor queue).
- ALTO Incremental Updates Using Server-Sent Events (SSE), which allows an ALTO server to expose ALTO cost values to specified time intervals (currently in the RFC editor queue).
- CDN Interconnection (CDNI) Advertisement using ALTO, which defines a new ALTO service to provide a CDNI footprint and capability advertisement interface (FCI) information (passed WG last call).
- ALTO Path Vector Extension, which introduces a new cost type to provide more detailed routing information using Abstract Network Elements (ANEs).
- ALTO Performance Cost Metrics, which presents a set of new network performance metrics, including network delay, jitter, packet loss rate, hop count, and bandwidth.
- Unified properties for the ALTO protocol, which generalizes the concept of ALTO endpoint properties by presenting those as ‘property maps’.
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.
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:
- Extensions for cellular networks
- Extensions for Multi-access Edge Computing (MEC)
- Extensions for huge data
- Extensions for inter-domain
- 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.
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.