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

"Narayanan, Vidya" <vidyan@qualcomm.com> Fri, 10 October 2008 06:07 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 D95E028C134; Thu, 9 Oct 2008 23:07:00 -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 7263028C107; Thu, 9 Oct 2008 23:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.599
X-Spam-Level:
X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 EhaeVr6YNmeE; Thu, 9 Oct 2008 23:06:57 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3C79428C0EA; Thu, 9 Oct 2008 23:06:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1223618863; x=1255154863; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20<vidyan@qualcomm.com>|To: =20"Dondeti,=20Lakshminath"=20<ldondeti@qualcomm.com>,=0D =0A=20=20=20=20=20=20=20=20Richard=20Barnes=0D=0A=09<rbar nes@bbn.com>|CC:=20"p2pi@ietf.org"=20<p2pi@ietf.org>,=20" 'iesg@ietf.org'"=20<iesg@ietf.org>,=0D=0A=20=20=20=20=20 =20=20=20"ietf@ietf.org"=20<ietf@ietf.org>|Date:=20Thu, =209=20Oct=202008=2023:07:21=20-0700|Subject:=20RE:=20[p2 pi]=20WG=20Review:=20Application-Layer=20Traffic=20Optimi zation=20(alto)|Thread-Topic:=20[p2pi]=20WG=20Review:=20A pplication-Layer=20Traffic=20Optimization=20(alto) |Thread-Index:=20Ackql3Fpab68XW5QR72WonF4ySZGDgABNt7g |Message-ID:=20<BE82361A0E26874DBC2ED1BA244866B9276373F3@ NALASEXMB08.na.qualcomm.com>|References:=20<2008100620353 2.B1D673A68AF@core3.amsl.com>=0D=0A=09<BE82361A0E26874DBC 2ED1BA244866B9276373BA@NALASEXMB08.na.qualcomm.com>=0D=0A =20<48EEB19C.4000303@bbn.com>=20<48EEE549.1080208@qualcom m.com>|In-Reply-To:=20<48EEE549.1080208@qualcomm.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5402"=3B=20a=3D"10547023"; bh=0+6fCBVuUYiM03QnPaWYwMIYrQCuT51h7Az6+bSpXOI=; b=LMxFKHIMJ1Rdd/hbIFkG5Q0Gv6wqa08YzBve5DunfuQlVEvJvepjK3dJ G+ioMj6/zWBbHUJNwV9BodQpFYCGs8i36khwV17TPrY6JONO88H27qjw8 4rgrRMMPbpe6Ls38XGvKi3Ke9LeFXRGzJfCaHiGCpcC/6uTwxRievR8Dm I=;
X-IronPort-AV: E=McAfee;i="5300,2777,5402"; a="10547023"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2008 23:07:26 -0700
Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A67PuM013850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Oct 2008 23:07:25 -0700
Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A67PWB005355 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Oct 2008 23:07:25 -0700
Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 9 Oct 2008 23:07:24 -0700
Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 9 Oct 2008 23:07:23 -0700
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: "Dondeti, Lakshminath" <ldondeti@qualcomm.com>, Richard Barnes <rbarnes@bbn.com>
Date: Thu, 09 Oct 2008 23:07:21 -0700
Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: Ackql3Fpab68XW5QR72WonF4ySZGDgABNt7g
Message-ID: <BE82361A0E26874DBC2ED1BA244866B9276373F3@NALASEXMB08.na.qualcomm.com>
References: <20081006203532.B1D673A68AF@core3.amsl.com> <BE82361A0E26874DBC2ED1BA244866B9276373BA@NALASEXMB08.na.qualcomm.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com>
In-Reply-To: <48EEE549.1080208@qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "p2pi@ietf.org" <p2pi@ietf.org>, "'iesg@ietf.org'" <iesg@ietf.org>, "ietf@ietf.org" <ietf@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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

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@qualcomm.com]
> Sent: Thursday, October 09, 2008 10:17 PM
> To: Richard Barnes
> Cc: Narayanan, Vidya; p2pi@ietf.org; 'iesg@ietf.org'
> 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@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