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

"Jan Seedorf" <Jan.Seedorf@nw.neclab.eu> Mon, 13 October 2008 15:03 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B962B3A6A3C; Mon, 13 Oct 2008 08:03:03 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2273D3A6A3C; Mon, 13 Oct 2008 08:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjqqBFIL4XtO; Mon, 13 Oct 2008 08:03:00 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 403A23A67F1; Mon, 13 Oct 2008 08:03:00 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EDA7D2C01918D; Mon, 13 Oct 2008 17:03:19 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvRhvgn0RHcH; Mon, 13 Oct 2008 17:03:19 +0200 (CEST)
Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (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: <B94940C43117794C9432FF5FF0CCB5064071B1@VENUS.office>
In-Reply-To: <20081006203532.B1D673A68AF@core3.amsl.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: AckqjtbBtBGZ4g7iSw6sF2KFPv5xZQCtViqA
References: <20081006203532.B1D673A68AF@core3.amsl.com>
From: "Jan Seedorf" <Jan.Seedorf@nw.neclab.eu>
To: <iesg@ietf.org>
Cc: p2pi@ietf.org
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

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: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On 
> Behalf Of IESG Secretary
> Sent: Monday, October 06, 2008 10:36 PM
> To: IETF Announcement list
> Cc: p2pi@ietf.org
> 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 (iesg@ietf.org) 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
> p2pi@ietf.org
> https://www.ietf.org/mailman/listinfo/p2pi
> 
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi