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

"Jan Seedorf" <> Mon, 13 October 2008 15:03 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id B962B3A6A3C; Mon, 13 Oct 2008 08:03:03 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2273D3A6A3C; Mon, 13 Oct 2008 08:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gjqqBFIL4XtO; Mon, 13 Oct 2008 08:03:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 403A23A67F1; Mon, 13 Oct 2008 08:03:00 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id EDA7D2C01918D; Mon, 13 Oct 2008 17:03:19 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nvRhvgn0RHcH; Mon, 13 Oct 2008 17:03:19 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id C1E7C2C000304; Mon, 13 Oct 2008 17:03:09 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 13 Oct 2008 17:03:00 +0200
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: AckqjtbBtBGZ4g7iSw6sF2KFPv5xZQCtViqA
References: <>
From: "Jan Seedorf" <>
To: <>
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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: [] On 
> Behalf Of IESG Secretary
> Sent: Monday, October 06, 2008 10:36 PM
> To: IETF Announcement list
> Cc:
> 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 ( 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 Chris Newman 
> (Chris.Newman at
> Applications Area Advisor:
> Lisa Dusseault (lisa at
> Mailing List:
> General Discussion: p2pi at
> To Subscribe:
> Archive:
> 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
p2pi mailing list