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

From: stefano previdi <[email-masked]>
Date: Fri, 10 Oct 2008 11:21:45 +0200

It was evident that the Dublin BoF went well but also evident that it ended
without consensus on the work that a ALTO WG should do/not do.

However, it looks to me that the 200 and more emails that followed the BoF,
allowed us to find some form of agreement on the direction ALTO community
should look at.

A few weeks later we had a new (revised) charter document. It has been sent
to the mailing list and slightly amended (nothing really substantial as I
recall). This also enforces the idea that we reached substantial consensus.

We may argue that consensus reached is not enough for a WG creation but
sincerely this is not my perception.

Naively, I tend to believe that a WG can be created once agreement exists on
problem statement and charter.

Once WG is created, consensus is anyway required for any standardization
process so, we'll have a lot of other opportunities for disagreement...

thanks.
s.

> From: "Narayanan, Vidya" <[email-masked]>
> Date: Thu, 9 Oct 2008 23:07:21 -0700
> To: "Dondeti, Lakshminath" <[email-masked]>, Richard Barnes
> <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]'" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> Conversation: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
> Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
> 
> 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:[email-masked]]
>> Sent: Thursday, October 09, 2008 10:17 PM
>> To: Richard Barnes
>> Cc: Narayanan, Vidya; [email-masked]; [email-masked]'
>> 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: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of IESG
>> Secretary
>>>>> Sent: Monday, October 06, 2008 1:36 PM
>>>>> To: IETF Announcement list
>>>>> Cc: [email-masked]
>>>>> 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
>>>>> ([email-masked]) 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
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>>> 
>>>> _______________________________________________
>>>> Ietf mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ietf
>>>> 
>>> _______________________________________________
>>> p2pi mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/p2pi
>>> 
>> 
> _______________________________________________
> p2pi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2pi

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Philip Levis <[email-masked]>
Date: Fri, 10 Oct 2008 08:39:45 -0700

On Oct 9, 2008, at 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  
> non-issue, purely a matter of wording.  In all of the "ALTO service"  
> provides ALTO information, which you might as well call an "ALTO  
> server".
>

I agree. This is such a pressing problem that blocking on terminology  
disputes which can be easily reconciled seems ill-advised. There was  
an excellent technical discussion on the list after the last IETF, and  
I think we reached at least rough consensus on the important points. I  
support moving forward.

Phil

---

From: Laird Popkin <[email-masked]>
Date: Fri, 10 Oct 2008 15:38:32 -0400 (EDT)

On a related note, I'd like to make sure that you guys know that, as we discussed in Dublin, the P4P Working Group is in the process of documenting the P4P protocol as used in our field tests, which we would like to offer to the ALTO group as input into the ALTO process. Our hope is to have this ready for the next IETF meeting. 

- Laird Popkin, CTO, Pando Networks 
  mobile: 646/465-0570 

----- Original Message ----- 
From: "Lisa Dusseault" <[email-masked]> 
To: "Lakshminath Dondeti" <[email-masked]> 
Cc: [email-masked], "IESG IESG" <[email-masked]>, [email-masked] 
Sent: Friday, October 10, 2008 3:21:02 PM (GMT-0500) America/New_York 
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) 

Lakshminath and Vidya, 

Vijay, Enrico and Stefano have said what I was going to say (e.g. below) -- as sponsoring AD for this charter I've been following the WG discussion, working with the rest of the IESG, and talking to people to confirm that there's better consensus on the list, even if there was confusion at the BOF.  This IETF Last Call is also part of confirming whether there's now consensus. 

It's difficult to write a charter without actually designing the solution. What would help with the charter, even now, is for people to write up proposals for the solution -- ideally in the form of Internet-Drafts.  I haven't yet selected chairs for the WG, so as you can imagine editors and authors aren't yet selected.  It would be most excellent to see some individual proposals before a committee gets their hands on them :) 

Lisa 

On Fri, Oct 10, 2008 at 11:36 AM, Vijay K. Gurbani < [email-masked] > wrote: 

 ... 

And since the BoF, much has changed to narrow the scope of the 
charter down to more manageable pieces as well as establish a 
channel with IRTF to move certain aspects of the work there 
(as the timeline in my previous email indicated.) 

Lakshminath Dondeti wrote: 

My perception and my understanding of some of the dissenting opinions 
was that some of those need to be worked out before creating a working group. 

But I believe that we have done exactly that: the list has been 
busy since Dublin on attempts to move the work forward in a manner 
that is conducive to all participants. 

_______________________________________________ p2pi mailing list [email-masked] https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Das, Saumitra" <[email-masked]>
Date: Thu, 16 Oct 2008 01:45:50 -0700

Citing one of the responses from Vijay on Oct 13 "For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are.  However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely where it will download the content from."

I agree ALTO does not determine content location but given a set of content locations by an application would provide a ranked order of "good" peers to download this from. However, a fundamental issue to consider is that simply using ISP information is not enough for a querying peer to determine wisely what to do. Unless there is a performance perspective to the goodness of peers, is there a real incentive for applications to adopt looking up ALTO since they anyway need to do a bunch of performance measurements. Applications typically may be happy simply saturating download bandwidth and not much else. Providing more information in ALTO could be a path to incentivising the users of the service. What this more information is should be up for debate.

We should also consider the more general question of when we are designing something for peer selection we are only designing a small piece of an information plane for the Internet. In this context, it may be useful to have information that can be aggregated across various applications and simply because specific BitTorrent clients may implement some such mechanisms does not mean that is a good design choice to leave it out of ALTO. An information plane (see the U Wash IPlane paper) of some kind may be something to consider given that we seem to solving only one part of the puzzle. Instead of each application building their own proprietary and application-specific information plane which is redundant and wasteful, such an information plane could potentially be something ALTO provides and can be reused across a wide range of services.

Thanks,
Saumitra Das