Application-Layer Traffic Optimization

Document Charter Application-Layer Traffic Optimization WG (alto)
Title Application-Layer Traffic Optimization
Last updated 2015-10-14
State Approved
WG State Active
IESG Responsible AD Mirja K├╝hlewind
Charter Edit AD Spencer Dawkins
Send notices to (None)


The ALTO working group was established in 2008 to devise a
request/response protocol for allowing a host to benefit from a server
that is more cognizant of the network infrastructure than the host
would be. The working group has developed an HTTP-based protocol
to allow hosts to benefit from the network infrastructure
by having access to a pair of maps: a topology map and a cost map.

The origins of the ALTO protocol lie in peer-to-peer (P2P)
applications, where the host is a peer in a P2P network and desires a
rendezvous with other peers for file sharing, real-time
communications, etc. ALTO is now being considered as a solution for
problems outside the P2P domain, such as in datacenter networks and
in content distribution networks (CDN) where exposing abstract
topologies helps applications.

To support the emerging new uses of ALTO, certain extensions are being
sought. These extensions can be classified as follows:

   o Protocol extensions for reducing the volume of on-the-wire data
     exchange required to align the ALTO server and
     clients. Extensions under consideration are mechanisms for
     delivering server-initiated notifications and partial updates of
     maps.  Efforts developed in other working groups such as
     Websockets and JSON-patch will be considered, as well as bespoke
     mechanisms specific to the ALTO protocol.

   o One or more alternatives to the base ALTO server discovery mechanism
     (RFC-to-be) to accommodate environments where (1) timely
deployment      of existing mechanisms, including the base ALTO
server discovery      mechanism, is unlikely, and/or (2) it is
desirable for an ALTO      client to be able to discover an ALTO
server outside its own      domain. The WG will consider mechanisms
that are in use or      defined by other WGs. If such discovery
mechanisms can be reused,      the WG will produce one or more
documents to specify how they may      be adopted as additional or
alternative ALTO server discovery      mechanisms. In the absence of
such existing work, the WG will      develop one or more
ALTO-specific server discovery mechanisms.      However, developing a
general-purpose service discovery mechanism      is not in scope.

   o Protocol extensions to convey a richer set of attributes to allow
     applications to determine not only "where" to connect
but also      "when" to connect.  Such additional
information will be related      both to endpoints (e.g. conveying
server load and cache      geo-location information for CDN use
cases) and to      endpoint-to-endpoint costs (e.g. bandwidth
calendaring to      represent time-averaged cost values in datacenter

     The working group will specify such extension in coordination
     with other working groups that have a focus on the related use
     cases.  The scope of extensions is not limited to those
     identified by the WGs, but is limited by the criteria set out

o    A document specifying how a graph representation format
     (originating, say, from a YANG data model) can be used in ALTO
and      optionally be exported by an ALTO server in addition to
network      and cost maps. The graph representation will be based on
existing      ALTO abstraction (e.g., PIDs) and complement existing
     path-based ALTO cost map representation. Together, they provide
     a more complete, potentially more compact, but still abstract
     representation of networks for informed traffic optimization
     among endpoints.  In settings with multiple application
source-      destination pairs with shared links, such a
representation will      help avoid bottleneck (or failed)
links.  The WG will not      consider, nor will it model,
topology internals not affecting      endpoints (e.g., routing
protocol internals or RIB data).

When the WG considers standardizing information that the ALTO server
could provide, the following criteria are important to ensure real

   - Can the ALTO service realistically discover that information?

   - Is the distribution of that information allowed by the operators
     of that service?

   - Can a client get that information without excessive privacy and
     information leakage concerns?  Extensions defining new
endpoint      properties should focus on exposing attributes of
endpoints      that are related to the goals of ALTO -- optimization
of      application-layer traffic -- as opposed to more general
     properties of endpoints. privacy and information leakage aspects
     of new endpoint properties will in any case be evaluated to the
     guidelines provided in the IANA considerations and Security
     Considerations of the ALTO protocol specification (RFC-to-be,
     sections 14.3 and 15.4 at IESG review time).

    - Is it information that a client cannot find easily some other

After these criteria are met, the importance of the data will be
considered for prioritizing standardization work, for example the
number of operators and clients that are likely to be able to provide
or use that particular data. In any case, this WG will not propose
standards on how congestion is signaled, remediated, or avoided, and
will not deal with information representing instantaneous network

Issues related to the specific content exchanged in systems that make
use of ALTO are also excluded from the WG's scope, as is the issue
dealing with enforcing the legality of the content.