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

Lakshminath Dondeti <ldondeti@qualcomm.com> Fri, 10 October 2008 05:16 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 C14BF3A69AF; Thu, 9 Oct 2008 22:16:38 -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 A1AB83A6952; Thu, 9 Oct 2008 22:16:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.999
X-Spam-Level:
X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, 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 q3SYLFdPHim8; Thu, 9 Oct 2008 22:16:35 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BB7A83A67D8; Thu, 9 Oct 2008 22:16:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1223615841; x=1255151841; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<48EEE549.1080208@qualcomm.com>|Date:=20Th u,=2009=20Oct=202008=2022:16:57=20-0700|From:=20Lakshmina th=20Dondeti=20<ldondeti@qualcomm.com>|User-Agent:=20Thun derbird=202.0.0.17=20(Windows/20080914)|MIME-Version:=201 .0|To:=20Richard=20Barnes=20<rbarnes@bbn.com>|CC:=20"Nara yanan,=20Vidya"=20<vidyan@qualcomm.com>,=20"p2pi@ietf.org "=20<p2pi@ietf.org>,=0D=0A=20=20=20=20=20=20=20=20"'iesg@ ietf.org'"=20<iesg@ietf.org>|Subject:=20Re:=20[p2pi]=20WG =20Review:=20Application-Layer=20Traffic=20Optimization =20(alto)|References:=20<20081006203532.B1D673A68AF@core3 .amsl.com>=09<BE82361A0E26874DBC2ED1BA244866B9276373BA@NA LASEXMB08.na.qualcomm.com>=20<48EEB19C.4000303@bbn.com> |In-Reply-To:=20<48EEB19C.4000303@bbn.com>|Content-Type: =20text/plain=3B=20charset=3DISO-8859-15=3B=20format=3Dfl owed|Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E =3DMcAfee=3Bi=3D"5300,2777,5402"=3B=20a=3D"10459624"; bh=6/iSUvxDzj/9KH4tRB2NDAwhZs2HN0ZWEyxndSIblQY=; b=HNfElECg8HstgK9sT+SBKjEBn36Juz0WFLQvCR/XmD/Jsij/0xZaj7k8 rElv9bMJ/jmu6/xPBOZwex6m/iLEuTlD3GmSQFiWUa/hoZFP/wNVdgNpq +7I3Y6STXwp+oN7sNxtUzs9kQQRHv61Tymg5e1YgLMBM+m3BCJXqASTog 8=;
X-IronPort-AV: E=McAfee;i="5300,2777,5402"; a="10459624"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2008 22:17:07 -0700
Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A5H7eu024243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Oct 2008 22:17:07 -0700
Received: from [10.50.68.165] (qconnect-10-50-68-165.qualcomm.com [10.50.68.165]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A5Gvqu023186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Oct 2008 22:17:02 -0700
Message-ID: <48EEE549.1080208@qualcomm.com>
Date: Thu, 09 Oct 2008 22:16:57 -0700
From: Lakshminath Dondeti <ldondeti@qualcomm.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Richard Barnes <rbarnes@bbn.com>
References: <20081006203532.B1D673A68AF@core3.amsl.com> <BE82361A0E26874DBC2ED1BA244866B9276373BA@NALASEXMB08.na.qualcomm.com> <48EEB19C.4000303@bbn.com>
In-Reply-To: <48EEB19C.4000303@bbn.com>
Cc: "p2pi@ietf.org" <p2pi@ietf.org>, "'iesg@ietf.org'" <iesg@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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

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