Skip to main content

Application-Layer Traffic Optimization
charter-ietf-alto-03-01

The information below is for an older proposed charter
Document Proposed charter Application-Layer Traffic Optimization WG (alto) Snapshot
Title Application-Layer Traffic Optimization
Last updated 2014-05-14
State Start Chartering/Rechartering (Internal Steering Group/IAB Review)
WG State Active
IESG Responsible AD Martin Duke
Charter edit AD Spencer Dawkins
Send notices to alto@ietf.org

charter-ietf-alto-03-01

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. It is a testament to the flexibility of the ALTO
protocol that it 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 Extensions to the base ALTO server discovery mechanism
(RFC-to-be) for deployment in heterogeneous network environments.
Mechanisms under consideration are extensions for third-party and
anycast-based server discovery. Because the issue of third-party
server discovery is broad and not particular to ALTO, the WG will
prefer to use server discovery mechanisms produced by other
working groups especially chartered to do so. In the absence of
such existing work, the WG will develop an ALTO-specific
third-party server discovery mechanism.

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 networks).

 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.

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
feasibility:

  • 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
    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 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
      way?

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

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.