Contrary to what some people seem to have interpreted my email to mean, I did actually say that the work is needed. I was noting the lack of consensus from the last BoF and I definitely feel a second BoF is more appropriate at this time to iron out the disagreements. However, I am still not trying to block the work - I am saying that there are some critical things to alter in the charter proposal. As Lakshminath notes, the notion of "service" vs. "server" is more than a terminology issue. It is important that we consider the possibility of ALTO being provided as a distributed service, potentially in an overlay context. I also see the charter being restrictive in terms of assuming a subset of information types to be provided by the ALTO server. We need to shoot for a much more generic and extensible mechanism. Another important missing piece is the ability for peers to publish information about themselves - without that, the request/response protocol alone carries much less value. Regards, Vidya > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@xxxxxxxxxxxx] > Sent: Thursday, October 09, 2008 10:17 PM > To: Richard Barnes > Cc: Narayanan, Vidya; p2pi@xxxxxxxx; 'iesg@xxxxxxxx' > Subject: Re: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > On 10/9/2008 6:36 PM, Richard Barnes wrote: > > On the contrary, I perceived pretty strong agreement at the > BoF that > > the ALTO problem, as expressed in the documents and > presentations, as > > an important one to solve. There was some disagreement about > > solutions, but there seemed to be agreement about the general idea > > that it would be useful to create an ALTO service that could help > > peers optimize their peer selection. > > Richard, > > The minutes > (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say > this: > > +++++++++++++++ > Many people agreed that this is important work for the IETF, also some > (less) people hummed against. Hum was inconclusive - some of the "no" > hums were (in Jon's words) vehement. > +++++++++++++++ > > Given that there was no consensus, it would have been nice if > the sponsoring AD(s) or the IESG explained what's going on, > but then transparency, it appears, is not really a goal in > this case. If the idea was to just go forward anyway, we > really wasted 3, may be 6 months. > The half measures are a waste of everyone's time. > > > > > The question of "service" versus "server" in the text is a complete > > non-issue, purely a matter of wording. > > No it is not; please see below. > > > In all of the "ALTO service" > > scenarios Vidya describes, there is ultimately a single host that > > provides ALTO information, which you might as well call an > "ALTO server". > > > > A distributed service is not necessarily provided by a single host. > > > Since it addresses an important problem, and a problem that many > > people agree is important, I support moving forward with this work. > > I for one think that there needs to be much more clarity on > the goals and the terminology before just moving forward and > producing useless RFCs. > > regards, > Lakshminath > > > > > --Richard > > > > > > > > Narayanan, Vidya wrote: > >> I am surprised to see that ALTO is being proposed for a WG > after the > >> last BoF concluded with no consensus whatsoever. I think a second > >> BoF is more appropriate than a WG on the topic at this time. That > >> said, I do see the need for this work, although I have > some comments > >> on the current direction. > >> > >> Overall, I think we should work with the notion of an ALTO > "service" > >> rather than specifically an ALTO "server". The ALTO > service may be > >> provided by a server, a cluster of distributed servers or as a > >> service in an overlay. Although some of the charter wording talks > >> about a "service" rather than a "server", there is enough > mention of > >> a "server" entity to imply a strict client-server protocol. > >> > >> As part of that, I think there are a couple of key things > that need > >> to be addressed here: > >> > >> - A protocol that allows peers (or ALTO clients) to publish > >> information about themselves as part of the ALTO service. > An example > >> of such information may be the uplink/downlink bandwidth > of the peer. > >> > >> - The ability to register information types with IANA and extend > >> these. The request/response protocol should be a generic enough > >> container for any information that peers can provide and look for, > >> plus what may be available from service providers, etc. > There may be > >> some guidelines on how such information types can be > registered and > >> we may start with default ones. > >> > >> Some further comments/questions inline. > >> > >>> -----Original Message----- > >>> From: ietf-announce-bounces@xxxxxxxx > >>> [mailto:ietf-announce-bounces@xxxxxxxx] On Behalf Of IESG > Secretary > >>> Sent: Monday, October 06, 2008 1:36 PM > >>> To: IETF Announcement list > >>> Cc: p2pi@xxxxxxxx > >>> Subject: 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@xxxxxxxx) 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. > >>> > >> > >> What does the above sentence mean? If we are putting such a list > >> together, we must also take into account needs from structured P2P > >> overlays such as those being specified in P2PSIP. > >> > >>> 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. > >>> > >> > >> Is this meant to allow for entities such as proxies to be > in the path? > >> > >>> - 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. > >>> > >> > >> Earlier, it is mentioned that the requirements document will > >> determine the types of information that are useful for P2P > >> applications. Given that, it seems premature to conclude > that the WG > >> should consider the above mentioned parameters. Also, as > I mentioned > >> earlier, I think it is essential to keep the protocol and message > >> formats extensible and allow for exchange of any > registered information type. > >> > >> Another question I have is about the assumptions around > expected peer > >> addressing models. Some of the above seems to hint at IP > addresses - > >> is this an assumption already? > >> > >>> - 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. > >>> > >> > >> Alternately, the clients may look for ALTO services within an > >> overlay. This can be modeled as service discovery within > the overlay > >> - I'm, however, not suggesting that we take on solutions for that. > >> > >>> 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? > >> > >> I'm not sure how useful it is for us to answer this question. The > >> protocol we develop simply needs to be a container for any > >> information that has a registered type and fits a certain format. > >> > >>> - 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. > >> > >> If we can build an extensible protocol, we don't need to > define all > >> possible kinds of information that get carried in it. > >> > >>> 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. > >>> > >> > >> I hope we can also look at the above from a generalized service > >> perspective rather than just a client-server perspective. > >> > >> Thanks, > >> Vidya > >> > >>> 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 > >>> > >>> > >>> > >>> _______________________________________________ > >>> IETF-Announce mailing list > >>> IETF-Announce@xxxxxxxx > >>> https://www.ietf.org/mailman/listinfo/ietf-announce > >>> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/ietf > >> > > _______________________________________________ > > p2pi mailing list > > p2pi@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/p2pi > > > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf