Application-Layer Traffic Optimization (ALTO) Protocol
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, alto mailing list <email@example.com>, alto chair <firstname.lastname@example.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/
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 email@example.com, 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.