[alto] WG Action: RECHARTER: Application-Layer Traffic Optimization (alto)

[IESG Secretary <[e-mail]>]

The Application-Layer Traffic Optimization (alto) working group in the
Applications Area of the IETF has been rechartered.  For additional
information, please contact the Area Directors or the working group
Chairs.

Application-Layer Traffic Optimization (alto)
---------------------------------------------
Current Status: Active Working Group

 Chairs:
     Jon Peterson <[e-mail]>
     Vijay Gurbani <[e-mail]>
     Enrico Marocco <[e-mail]>

 Applications Area Directors:
     Alexey Melnikov <[e-mail]>
     Peter Saint-Andre <[e-mail]>

 Applications Area Advisor:
     Peter Saint-Andre <[e-mail]>

 Mailing Lists:
     General Discussion: [e-mail]
     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