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

"Daniel Park" <soohongp@gmail.com> Fri, 10 October 2008 04:28 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 ED7673A67EC; Thu, 9 Oct 2008 21:28:35 -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 0AB4B3A67EC for <p2pi@core3.amsl.com>; Thu, 9 Oct 2008 21:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 rR-Uz5QCJvpd for <p2pi@core3.amsl.com>; Thu, 9 Oct 2008 21:28:32 -0700 (PDT)
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by core3.amsl.com (Postfix) with ESMTP id 3D50E3A6359 for <p2pi@ietf.org>; Thu, 9 Oct 2008 21:28:32 -0700 (PDT)
Received: by wr-out-0506.google.com with SMTP id c49so197364wra.17 for <p2pi@ietf.org>; Thu, 09 Oct 2008 21:29:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=36HJb4ph/DZaT/I1qn8eAOZ/Q2FbjuwocLJnde3r7Mw=; b=dnTfVJfT1h96JWpFlotO1ex3WECAQGD5QN2kOo4cMJd3ewM2WF6xo9V2iLU9lO+9xb dQoRGiFMIwr7jf5NDC3T2rIW+rcLLngDBMgom5vXHyGkCg+6BDKkquje0dr6Lczyu2my WJt+3wwB7eT2agYb4JAwtboGRUB1WOfgxl8bA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=dY8X9cQRLH/8TP/c/l1ZWG7QRbMq8HM8SweRhgMOG982cgbizzesGd0TT+Tx1OD2fv xAU2ZkqG74G+/jqUJmK28xm/YafVfWWZG1mQhHRb/odiLLMsK0G8532390sy7W1bmKwC QzG64S3ovEBbAhfvcKr6bnmiq42RF5t8g6OCM=
Received: by 10.90.101.17 with SMTP id y17mr1055797agb.108.1223612947804; Thu, 09 Oct 2008 21:29:07 -0700 (PDT)
Received: by 10.90.26.11 with HTTP; Thu, 9 Oct 2008 21:29:07 -0700 (PDT)
Message-ID: <f7c7d76e0810092129p120cf75cra1c1d3d02c23bf00@mail.gmail.com>
Date: Fri, 10 Oct 2008 13:29:07 +0900
From: "Daniel Park" <soohongp@gmail.com>
To: "Richard Barnes" <rbarnes@bbn.com>
In-Reply-To: <48EEB19C.4000303@bbn.com>
MIME-Version: 1.0
References: <20081006203532.B1D673A68AF@core3.amsl.com> <BE82361A0E26874DBC2ED1BA244866B9276373BA@NALASEXMB08.na.qualcomm.com> <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-Type: multipart/mixed; boundary="===============1428086272=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

I also agree to move it forward. One example: ALTO issue is quickly coming
up in the IPTV business. P2P for IPTV service already takes place in some of
standard bodies (e.g., DVB, EBU, etc...).  So, it's a good timing not to
missing over the important business changes...

-- 
Daniel Park [at] Samsung Electronics
Standard Architect, blog.naver.com/natpt



On Fri, Oct 10, 2008 at 10:36 AM, Richard Barnes <rbarnes@bbn.com> 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.
>
> The question of "service" versus "server" in the text is a complete
> non-issue, purely a matter of wording.  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".
>
> Since it addresses an important problem, and a problem that many people
> agree is important, I support moving forward with this work.
>
> --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