Skip to main content

Application-Layer Traffic Optimization (ALTO) Protocol
draft-ietf-alto-protocol-27

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    alto mailing list <alto@ietf.org>,
    alto chair <alto-chairs@tools.ietf.org>
Subject: Protocol Action: 'ALTO Protocol' to Proposed Standard (draft-ietf-alto-protocol-27.txt)

The IESG has approved the following document:
- 'ALTO Protocol'
  (draft-ietf-alto-protocol-27.txt) as Proposed Standard

This document is the product of the Application-Layer Traffic
Optimization Working Group.

The IESG contact persons are Spencer Dawkins and Martin Stiemerling.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-alto-protocol/


Ballot Text

Technical Summary

   Applications using the Internet already have access to some topology
   information of Internet Service Provider (ISP) networks.  For
   example, views to Internet routing tables at looking glass servers
   are available and can be practically downloaded to many network
   application clients.  What is missing is knowledge of the underlying
   network topologies from the point of view of ISPs.  In other words,
   what an ISP prefers in terms of traffic optimization -- and a way to
   distribute it.

   The Application-Layer Traffic Optimization (ALTO) Service provides
   network information (e.g., basic network location structure and
   preferences of network paths) with the goal of modifying network
   resource consumption patterns while maintaining or improving
   application performance.  The basic information of ALTO is based on
   abstract maps of a network.  These maps provide a simplified view,
   yet enough information about a network for applications to
   effectively utilize them.  Additional services are built on top of
   the maps.

   This document describes a protocol implementing the ALTO Service.
   Although the ALTO Service would primarily be provided by ISPs, other
   entities such as content service providers could also operate an ALTO
   Service.  Applications that could use this service are those that
   have a choice to which end points to connect.  Examples of such
   applications are peer-to-peer (P2P) and content delivery networks.

Working Group Summary

  The specification process has been particularly long and
  articulated. The WG had to make many decisions -- the architectural
  ones reflected in the related requirements document -- that took
  time. However, quite broad consensus was reached on almost all of
  them.

Document Quality

  The document shepherd has followed the specification process
  closely, implementing a proof-of-concept client application himself
  (http://alto.tilab.com/alto-xkcd/). He has proofread the final
  version of the document and believes it is ready for publication.

  Implementations: three implementations with some interoperability
  were demostrated during a "running code show" organized at
  IETF80. Seven client and five server implementations were tested in
  an "interoperability event" at IETF81, with pretty good results
  (http://www.ietf.org/mail-archive/web/alto/current/msg01181.html). A
  second interoperability event was arranged during IETF85, were four
  server and two client implementations were tested against 21 test
  cases, with again good success rates (last slide of
  http://www.ietf.org/proceedings/85/slides/slides-85-alto-0.pdf).

  Expert supervision: since the protocol, despite being developed in
  TSV, is an application level protocol, based on HTTP and following a
  REST-ful approach, Peter Saint-Andre (also former responsible AD for
  ALTO, before the WG was moved to TSV) was appointed as APPS expert
  and has supervised the specification process in its crucial phases
  (Peter stepped back as Tech advisor at a later phase). Other experts
  from APPS (Martin Thomson, Alexey Melnikov), SEC (Richard Barnes,
  Hannes Tshofenig) and OPS (David Harrington, Benoit Claise) have at
  some point been involved and provided feedback on various aspects.

  Ted Hardie kindly provided a early apps-dir review
  (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05406.html)
  that helped in improving the document quality quite a lot.

  A Media Type review was requested on media-types@ietf.org, but was
  never formally performed. However, in some private exchages
  triggered by the review request, no issues were raised.

Personnel

  Enrico Marocco is the document shepherd, Spencer Dawkins is the
  responsible AD.

RFC Editor Note