Application-Layer Traffic Optimization (alto)

Last Modified: 2009-04-22

Additional information is available at tools.ietf.org/wg/alto

Chair(s):

  • Jon Peterson <jon.peterson@neustar.biz>

  • Enrico Marocco <enrico.marocco@telecomitalia.it>

  • Vijay Gurbani <vkg@bell-labs.com>

    Applications Area Director(s):

  • Lisa Dusseault <Lisa.Dusseault@messagingarchitects.com>
  • Alexey Melnikov <alexey.melnikov@isode.com>

    Applications Area Advisor:

  • Lisa Dusseault <Lisa.Dusseault@messagingarchitects.com>

    Mailing Lists:

    General Discussion: alto@ietf.org
    To Subscribe: https://www.ietf.org/mailman/listinfo/alto
    Archive: http://www.ietf.org/mail-archive/web/alto/current/maillist.html

    Description of Working Group:

    A significant part of the Internet traffic today is generated by
    peer-to-peer (P2P) applications used for file sharing, real-time
    communications, and live media streaming.  P2P applications exchange
    large amounts of data, often uploading as much as downloading.  In
    contrast to client/server architectures, P2P applications often must
    choose one or more suitable candidates from a selection of peers
    offering the same resource or service.

    One of the advantages of P2P systems comes from redundancy in resource
    availability.  This requires choosing among a list of peers, yet
    applications
    have at best incomplete information to help the selection, e.g., topology
    of the network.

    Applications can sometimes obtain network information dynamically
    or measure link performance with respect to particular peers, but
    even when this is an option it takes time. The application cannot
    always start out with an optimal arrangement of peers, thus risking
    at least temporary poor performance and
    excessive cross-domain traffic.  Providing more information for use in
    peer selection can improve P2P performance and lower ISP costs.

    The Working Group will design and specify an Application-Layer Traffic
    Optimization (ALTO) service that will provide applications with
    information to perform better-than-random initial peer selection.
    ALTO services may take different approaches at balancing factors
    such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the
    user, etc.  The WG will consider the needs of BitTorrent, tracker-less
    P2P, and other applications, such as content delivery networks (CDN)
    and mirror selection.

    The WG will focus on the following items:

    - A "problem statement" document providing a description of the
    problem and a common terminology.

    - A requirements document.  This document will list requirements for
    the ALTO service, identifying, for example, types of information
    P2P applications may need for optimizing their choices.

    - A request/response protocol for querying the ALTO service to obtain
    information useful for peer selection, and a format for requests and
    responses
    If the requirements analysis identifies the need to allow clients to
    delegate third-parties to query the ALTO service on their behalf, the
    WG will ensure that the protocol provides a mechanism to assert the
    consent of the delegating client.

    - A document defining core request and response formats and semantics
    to communicate network preferences to applications.  Since ALTO
    services may be run by entities with different level of knowledge
    about the underlying network, such preferences may have different
    representations. Initially the WG will consider: IP ranges to prefer
    and to avoid, ranked lists of the peers requested by the client,
    information about topological proximity and approximate geographic
    locations.  Other usages will be considered as charter additions
    once the work for the initial services has been completed.

    - In order to query the ALTO server, clients must first know one or
    more ALTO servers that might provide useful information.  The WG
    will look at service discovery mechanisms that are in use, or
    defined elsewhere (e.g. based on DNS SRV records or DHCP options).
    If such discovery mechanisms can be reused, the WG will produce a
    document to specify how they may be adopted for locating such
    servers.  However, a new, general-purpose service discovery
    mechanism is not in scope.

    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?

    - Is it information that a client will find useful?

    - Can a client get that information without excessive privacy concerns
    (e.g. by sending large lists of peers)?

    - 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.  Such issues belong to other IETF areas and will be treated
    accordingly by the specific area.

    This WG will focus solely on the communication protocol between
    applications and ALTO servers.  Note that ALTO services may be useful
    in client-server environments as well as P2P environments, although
    P2P environments are the first focus.  If, in the future, the IETF
    considers changes to other protocols for actually implementing ALTO
    services (e.g. application-layer protocols for Internet coordinate
    systems, routing protocol extensions for ISP-based solutions), such
    work will be done in strict coordination with the appropriate WGs.

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

    Goals and Milestones:

    Apr 2009  Working Group Last Call for problem statement
    Jun 2009  Submit problem statement to IESG as Informational
    Aug 2009  Working Group Last Call for requirements document
    Oct 2009  Submit requirements document to IESG as Informational
    Jan 2010  Working Group Last Call for request/response protocol
    Jan 2010  Working Group Last Call for usage document for communicating network preferences
    Mar 2010  Submit request/response protocol to IESG as Proposed Standard
    Mar 2010  Submit usage document to IESG as Proposed Standard
    May 2010  Working Group Last Call of discovery mechanism
    Jul 2010  Submit discovery mechanism to IESG as Proposed Standard
    Aug 2010  Dissolve or re-charter

    Internet-Drafts:

    Application-Layer Traffic Optimization (ALTO) Requirements (35751 bytes)
    Application-Layer Traffic Optimization (ALTO) Problem Statement (32532 bytes)

    No Request For Comments

    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.