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

[Lakshminath Dondeti <[e-mail]>]

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