* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Alto Status Pages

Application-Layer Traffic Optimization (Active WG)
Tsv Area: Mirja Kühlewind, Spencer Dawkins | 2008-Nov-12 —  
Chairs
 
 


2018-10-01 charter

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

 Charter

 Current Status: Active

 Chairs:
     Jan Seedorf <ietf@j-f-s.de>
     Vijay K. Gurbani <vijay.gurbani@gmail.com>

 Transport Area Directors:
     Spencer Dawkins <spencerdawkins.ietf@gmail.com>
     Mirja Kühlewind <ietf@kuehlewind.net>

 Transport Area Advisor:
     Mirja Kühlewind <ietf@kuehlewind.net>

 Mailing Lists:
     General Discussion: alto@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/alto
     Archive:            https://mailarchive.ietf.org/arch/browse/alto/

Description of Working Group:

  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 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, but is limited by the criteria set out
       below.

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

Goals and Milestones:
  Done     - Submit deployment considerations document to IESG as Informational
  Mar 2017 - Submit cost property extension document
  Jul 2017 - Submit partial updates document
  Jul 2017 - Submit server-initiated notifications document
  Jul 2017 - Submit endpoing property extension document
  Nov 2017 - Submit network graph format document
  Nov 2017 - Submit alternative server discovery document
  Nov 2017 - Recharter or dissolve working group
  Nov 2017 - Submit alto service for CDNI FCI objects


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/alto/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -