Application-Layer Traffic Optimization
|Document||Charter||Application-Layer Traffic Optimization WG (alto)|
|Title||Application-Layer Traffic Optimization|
|IESG||Responsible AD||Martin Duke|
|Charter edit AD||Martin Duke|
|Send notices to||(None)|
The ALTO working group was established in 2008 to devise a request/response protocol to allow a host to choose optimal paths to resources from a server with more knowledge of the network. The working group developed an HTTP-based protocol, and reported proof-of-concepts of ALTO based solutions supporting applications such as content distribution networks (CDN). To support current and future deployments of ALTO, the working group is now chartered for the following activities: o Develop operational support tools for ALTO. Based on experience from deployments, the advice in RFC 7971, and the latest opinions and techniques from the Operations and Management Area, the working group will develop tools to configure, operate, and manage the ALTO protocol and networks that use ALTO. This may include YANG models and Operations, Administration, and Maintenance (OAM) mechanisms, in consultation with the OPS area and the IPPM WG. The working group may also update RFC 7971 in the light of new experience and protocol features that were added to ALTO after that RFC was published. o Support for modern transport protocols. ALTO only uses the capabilities of HTTP version 1. While ALTO can operate successfully over any version of HTTP, it would benefit from leveraging HTTP/2 and HTTP/3 capabilities such as push. The WG will produce an ALTO extension that leverages these capabilities if they can be shown to improve performance. o The WG will place special emphasis on the normal group activities of collecting deployment experience, exploring use cases, and protocol maintenance. The working group will not develop protocol extensions for new use cases until it has been re-chartered specifically for that purpose. A report on wide-scale deployment of ALTO and documented demand for new use cases will be critical to the decision to recharter or close the Working Group. At the conclusion of the OAM and HTTP2/3 deliverables, plus completion of any adopted drafts emerging from urgent protocol maintenance needs, the working group will close or recharter. Furthermore, the Area Director and chairs will assess the state of the deliverables at the end of 2022. If the Area Director judges that delivery of these documents is not imminent, and that documentation of wide deployment is missing, the AD may close the working group immediately. The AD may also either move each adopted document to another working group for completion, or abandon the work.