Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

["Jan Seedorf" <[e-mail]>]

I have been note-taker at the ALTO BoF in Dublin and I have been following the discussions on the mailing list since the BoF. I believe that the issues which prevented consensus during the ALTO BoF in Dublin have been discussed intensively on the mailing list and been resolved in the meantime. Thus, I support moving forward to a WG.

	- Jan

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of IESG Secretary
> Sent: Monday, October 06, 2008 10:36 PM
> To: IETF Announcement list
> Cc: [e-mail]
> Subject: [p2pi] WG Review: Application-Layer Traffic 
> Optimization (alto)
> 
> A new IETF working group has been proposed in the 
> Applications Area.  The IESG has not made any determination 
> as yet.  The following draft charter was submitted, and is 
> provided for informational purposes only.  Please send your 
> comments to the IESG mailing list ([e-mail]) by Monday, 
> October 13, 2008.
> 
> Application-Layer Traffic Optimization (alto) 
> =============================================
> Last Modified: 2008-09-29
> 
> Current Status: Proposed Working Group
> 
> Chair(s): TBD
> 
> Applications Area Director(s):
> 
> Lisa Dusseault (lisa at osafoundation.org) Chris Newman 
> (Chris.Newman at sun.com)
> 
> Applications Area Advisor:
> 
> Lisa Dusseault (lisa at osafoundation.org)
> 
> Mailing List:
> 
> General Discussion: p2pi at ietf.org
> To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi
> Archive: http://www.ietf.org/pipermail/p2pi/
> 
> Description of Working Group:
> 
> A significant part of the Internet traffic today is generated 
> by peer-to-peer (P2P) applications used for file sharing, 
> real-time communications, and live media streaming.  P2P 
> applications exchange large amounts of data, often uploading 
> as much as downloading.  In contrast to client/server 
> architectures, P2P applications often have a selection of 
> peers and must choose.
> 
> One of the advantages of P2P systems comes from redundancy in 
> resource availability.  This requires choosing among download 
> locations, yet applications have at best incomplete 
> information about the topology of the network.  Applications 
> can sometimes make empirical measurements of link 
> performance, but even when this is an option it takes time.
> The application cannot always start out with an optimal 
> arrangement of peers, thus causing at least temporary reduced 
> performance and excessive cross-domain traffic.  Providing 
> more information for use in peer selection can improve P2P 
> performance and lower ISP costs.
> 
> The Working Group will design and specify an 
> Application-Layer Traffic Optimization (ALTO) service that 
> will provide applications with information to perform 
> better-than-random initial peer selection.
> ALTO services may take different approaches at balancing 
> factors including maximum bandwidth, minimum cross-domain 
> traffic, lowest cost to the user, etc.  The WG will consider 
> the needs of BitTorrent, tracker-less P2P, and other 
> applications, such as content delivery networks (CDN) and 
> mirror selection.
> 
> The WG will focus on the following items:
> 
> - A "problem statement" document providing a description of the
>   problem and a common terminology.
> 
> - A requirements document.  This document will list 
> requirements for  the ALTO service, identifying, for example, 
> what kind of information  P2P applications will need for 
> optimizing their choices.
> 
> - A request/response protocol for querying the ALTO service 
> to obtain information useful for peer selection, and a format 
> for requests and
> responses.   The WG does not require intermediaries between the ALTO
> server and the peer querying it.  If the requirements 
> analysis identifies the need to allow clients to delegate 
> third-parties to query the ALTO service on their behalf, the 
> WG will ensure that the protocol provides a mechanism to 
> assert the consent of the delegating client.
> 
> - A document defining core request and response formats and 
> semantics to communicate network preferences to applications. 
>  Since ALTO services may be run by entities with different 
> level of knowledge about the underlying network, such  
> preferences may have different representations. Initially the 
> WG will consider: IP ranges to prefer and to avoid, ranked 
> lists of the peers requested by the client, information about 
> topological proximity and approximate geographic locations.  
> Other usages will be considered as extensions to the charter 
> once the work for the initial services has been completed.
> 
> - In order to query the ALTO server, clients must first know 
> one or more ALTO servers that might provide useful 
> information.  The WG will look at service discovery 
> mechanisms that are in use, or defined elsewhere (e.g.
> based on DNS SRV records or DHCP options).  If such discovery 
> mechanisms can be reused, the WG will produce a document to 
> specify how they may be adopted for locating such servers.  
> However, a new, general-purpose service discovery mechanism 
> is not in scope.
> 
> 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 technically provide that information?
> - Is the ALTO service willing to obtain and divulge that information?
> - Is it information that a client will find useful?
> - Can a client get that information without excessive privacy concerns
>   (e.g. by sending large lists of peers)?
> - Is it information that a client cannot find easily some other way?
> 
> After these criteria are met, the generality 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. 
> Such issues belong to other IETF areas and will be treated 
> accordingly by the specific area.
> 
> This WG will focus solely on the communication protocol 
> between applications and ALTO servers.  Note that ALTO 
> services may be useful in client-server environments as well 
> as P2P environments, although P2P environments are the first 
> focus.  If, in the future, the IETF considers changes to 
> other protocols for actually implementing ALTO servers (e.g. 
> application-layer protocols for Internet coordinate systems, 
> routing protocol extensions for ISP-based solutions), such 
> work will be done in strict coordination with the appropriate WGs.
> 
> Issues related to the content exchanged in P2P systems are 
> also excluded from the WG's scope, as is the issue dealing 
> with enforcing the legality of the content.
> 
> Goals and Milestones (very tentative dates):
> 
> Apr 2009: Working Group Last Call for problem statement Jun 
> 2009: Submit problem statement to IESG as Informational Aug 
> 2009: Working Group Last Call for requirements document Oct 
> 2009: Submit requirements document to IESG as Informational 
> Jan 2010: Working Group Last Call for request/response 
> protocol Jan 2010: Working Group Last Call for usage document 
> for communicating network preferences Mar 2010: Submit 
> request/response protocol to IESG as Proposed Standard Mar 
> 2010: Submit usage document to IESG as Proposed Standard May 
> 2010: Working Group Last Call of discovery mechanism Jul 
> 2010: Submit discovery mechanism to IESG as Proposed Standard 
> Aug 2010: Dissolve or re-charter
> 
> Initial Drafts for Consideration
> - draft-marocco-alto-problem-statement-02 -- 
> Application-Layer Traffic Optimization (ALTO) Problem Statement
> - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization
> (ALTO) Requirements
> 
> 
> 
> _______________________________________________
> p2pi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2pi
> 
_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi