Re: WG Review: Application-Layer Traffic Optimization (alto)
Marshall Eubanks <tme@multicasttech.com> Fri, 10 October 2008 12:01 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A0B28C1D0; Fri, 10 Oct 2008 05:01:03 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C9E28C1AB; Fri, 10 Oct 2008 05:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.206
X-Spam-Level:
X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 DunScT+xWLQD; Fri, 10 Oct 2008 05:00:58 -0700 (PDT)
Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id E4F6B3A6ADF; Fri, 10 Oct 2008 05:00:32 -0700 (PDT)
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13323589; Fri, 10 Oct 2008 08:00:57 -0400
Message-Id: <C27FC19F-A2AC-46D2-97F8-E45FF54FB377@multicasttech.com>
From: Marshall Eubanks <tme@multicasttech.com>
To: iesg@ietf.org
In-Reply-To: <20081006203532.B1D673A68AF@core3.amsl.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: WG Review: Application-Layer Traffic Optimization (alto)
Date: Fri, 10 Oct 2008 08:00:56 -0400
References: <20081006203532.B1D673A68AF@core3.amsl.com>
X-Mailer: Apple Mail (2.929.2)
Cc: p2pi@ietf.org, IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
I support this moving forward. My reading of the room in Dublin was that there was serious support for this and certainly a critical mass to move forward. Some comments in the charter below. This document clearly needs some more work. As a overall comment, I think it is premature to discuss ALTO "servers" and would keep the charter focused on describing the ALTO "service." I do not see consensus at this moment as to a central service solution versus a distributed solution. Regards Marshall On Oct 6, 2008, at 4:35 PM, IESG Secretary wrote: > 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. s/choose/choose the best peer or peers to exchange data with/ > > > 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 This is strange wording, as WG themselves are not protocols. More fundamentally, is this a requirement ? If so, it seems premature before a requirements draft is adopted. Saying "The ALTO server" here also seems limiting - is there a solution draft describing a server ? Others have already commented on central servers versus a distributed system, and to me the charter is not the place to make such decisions. I would remove this sentence entirely. > > 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 s/server/service/ s/know/find/ > > 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 s/server/service/ > > could provide, the following criteria are important to ensure real > feasibility. > > - Can the ALTO service technically provide that information? I think that what is meant here is "Can the ALTO service realistically discover that information?" > > - Is the ALTO service willing to obtain and divulge that information? Do computers have free will ? More seriously, it seems very odd to assume that a P2P service will not do something that the owners of the peers want it to do. In my opinion that drives P2P adoption much more than the efficiencies of bandwidth sharing. > > - 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 What is meant by "the generality of the data" ? > > 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 Does this mean that congestion is not an issue to consider ? If the closest peer to me was totally congested and had no available bandwidth, isn't that something that I would want to know ? > > will not deal with information representing instantaneous network > state. What is meant by "information representing instantaneous network state" ? Isn't this a protocol to share information about the state of the network ? Or is this an attempt to separate network topology from network performance ? But should network performance also be an issue ? > > 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 Not according to the previous paragraphs. Service discovery is not part of this communication protocol, Load balancing is not part of this, etc. I would suggest changing "solely" to "primarily" > > 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, What is an Internet coordinate system ? > > 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 s/also// > > excluded from the WG's scope, as is the issue dealing with enforcing s/is the issue/are issues/ > > the legality of the content. s/the legality of the content/copyrights/ > > > 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 > > Regards Marshall > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- RE: WG Review: Application-Layer Traffic Optimiza… Narayanan, Vidya
- Re: WG Review: Application-Layer Traffic Optimiza… Sam Hartman
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: WG Review: Application-Layer Traffic Optimiza… Marshall Eubanks
- Re: [p2pi] WG Review: Application-Layer Traffic O… Enrico Marocco
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lakshminath Dondeti
- Re: [p2pi] WG Review: Application-Layer Traffic O… stefano previdi
- Re: [p2pi] WG Review: Application-Layer Traffic O… Philip Levis
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lisa Dusseault
- Re: [p2pi] WG Review: Application-Layer Traffic O… Alissa Cooper
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: [p2pi] WG Review: Application-Layer Traffic O… Marshall Eubanks
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lakshminath Dondeti
- Re: [p2pi] WG Review: Application-Layer Traffic O… Enrico Marocco
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lakshminath Dondeti
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: WG Review: Application-Layer Traffic Optimiza… Pekka Savola
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- Re: [p2pi] WG Review: Application-Layer Traffic O… Laird Popkin
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- RE: [p2pi] WG Review: Application-Layer Traffic O… Martin Stiemerling
- RE: [p2pi] WG Review: Application-Layer Traffic O… Jan Seedorf
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- Re: WG Review: Application-Layer Traffic Optimiza… Lars Eggert
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lars Eggert
- RE: [p2pi] WG Review: Application-Layer Traffic O… Song Haibin
- Re: [p2pi] WG Review: Application-Layer Traffic O… Laird Popkin
- Re: [p2pi] WG Review: Application-Layer Traffic O… Nicholas Weaver
- Re: [p2pi] WG Review: Application-Layer Traffic O… Karl Auerbach
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: [p2pi] WG Review: Application-Layer Traffic O… Ye WANG
- Re: [p2pi] WG Review: Application-Layer Traffic O… Philip Levis
- RE: [p2pi] WG Review: Application-Layer Traffic O… Song Haibin
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lisa Dusseault
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: [p2pi] WG Review: Application-Layer Traffic O… Laird Popkin
- Re: [p2pi] WG Review: Application-Layer Traffic O… Das, Saumitra
- RE: [p2pi] WG Review: Application-Layer Traffic O… Woundy, Richard
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: [p2pi] WG Review: Application-Layer Traffic O… Enrico Marocco
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- RE: [p2pi] WG Review: Application-Layer Traffic O… toby.moncaster
- Re: [p2pi] WG Review: Application-Layer Traffic O… Laird Popkin
- Openness for IETF-sponsored events Ted Hardie
- Re: Openness for IETF-sponsored events Andrew G. Malis
- Re: [p2pi] WG Review: Application-Layer Traffic O… Nicholas Weaver
- Re: [p2pi] WG Review: Application-Layer Traffic O… Stanislav Shalunov
- RE: WG Review: Application-Layer Traffic Optimiza… Narayanan, Vidya
- RE: [p2pi] WG Review: Application-Layer Traffic O… Yu-Shun Wang
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- RE: [p2pi] WG Review: Application-Layer Traffic O… Yu-Shun Wang