Charter for Working Group

The ALTO working group was established in 2008 to devise arequest/response protocol for allowing a host to benefit from a serverthat is more cognizant of the network infrastructure than the hostwould be. The working group has developed an HTTP-based protocolto allow hosts to benefit from the network infrastructureby 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 arendezvous with other peers for file sharing, real-timecommunications, 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 beingsought. 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 servercould provide, the following criteria are important to ensure realfeasibility:

- 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 beconsidered for prioritizing standardization work, for example thenumber of operators and clients that are likely to be able to provideor use that particular data. In any case, this WG will not proposestandards on how congestion is signaled, remediated, or avoided, andwill not deal with information representing instantaneous networkstate.

Issues related to the specific content exchanged in systems that makeuse of ALTO are also excluded from the WG's scope, as is the issuedealing with enforcing the legality of the content.