Application-Layer Traffic Optimization (alto)
---------------------------------------------

Charter
Last Modified: 2011-12-09

Current Status: Active Working Group

Chair(s):
    Enrico Marocco  <[email protected]>
    Vijay Gurbani  <[email protected]>

Transport Area Director(s):
    David Harrington  <[email protected]>
    Wesley Eddy  <[email protected]>

Transport Area Advisor:
    David Harrington  <[email protected]>

Technical Advisor(s):
    Peter Saint-Andre  <[email protected]>

Mailing Lists:
    General Discussion:[email protected]
    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 specification of core request and response formats and semantics
 to communicate network preferences to applications.  Since ALTO
 services may be run by entities with different levels 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.

 - An informational document discussing deployment related issues and
 documenting lessons learned from early implementation experiences.

 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:

  Done         Working Group Last Call for problem statement

  Done         Submit problem statement to IESG as Informational

  Jan 2011       Working Group Last Call for requirements document

  Jan 2011       Working Group Last Call for request/response protocol

  Mar 2011       Submit request/response protocol to IESG as Proposed Standard

  Mar 2011       Submit requirements document to IESG as Informational

  May 2011       Working Group Last Call of deployment considerations document

  Aug 2011       Submit deployment considerations document to IESG as
               Informational

  Nov 2011       Working Group Last Call of discovery mechanism

  Feb 2012       Submit discovery mechanism to IESG as Proposed Standard

  Mar 2012       Dissolve or re-charter


Internet-Drafts:

Posted Revised         I-D Title   <Filename>
------ ------- --------------------------------------------
Apr 2009 Jan 2012   <draft-ietf-alto-reqs-13.txt>
               Application-Layer Traffic Optimization (ALTO) Requirements

Dec 2009 Oct 2011   <draft-ietf-alto-protocol-10.txt>
               ALTO Protocol

Feb 2011 Nov 2011   <draft-ietf-alto-deployments-03.txt>
               ALTO Deployment Considerations

May 2011 Sep 2011   <draft-ietf-alto-server-discovery-02.txt>
               ALTO Server Discovery

Request For Comments:

 RFC   Stat Published     Title
------- -- ----------- ------------------------------------
RFC5693 I    Oct 2009    Application-Layer Traffic Optimization (ALTO) Problem
                      Statement

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.