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

"Daniel Park" <> Fri, 10 October 2008 04:28 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id ED7673A67EC; Thu, 9 Oct 2008 21:28:35 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AB4B3A67EC for <>; Thu, 9 Oct 2008 21:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rR-Uz5QCJvpd for <>; Thu, 9 Oct 2008 21:28:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3D50E3A6359 for <>; Thu, 9 Oct 2008 21:28:32 -0700 (PDT)
Received: by with SMTP id c49so197364wra.17 for <>; Thu, 09 Oct 2008 21:29:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id y17mr1055797agb.108.1223612947804; Thu, 09 Oct 2008 21:29:07 -0700 (PDT)
Received: by with HTTP; Thu, 9 Oct 2008 21:29:07 -0700 (PDT)
Message-ID: <>
Date: Fri, 10 Oct 2008 13:29:07 +0900
From: "Daniel Park" <>
To: "Richard Barnes" <>
In-Reply-To: <>
MIME-Version: 1.0
References: <> <> <>
Cc: "" <>, "" <>
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1428086272=="

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,

On Fri, Oct 10, 2008 at 10:36 AM, 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.
> 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:
>>> [] On Behalf Of IESG Secretary
>>> Sent: Monday, October 06, 2008 1:36 PM
>>> To: IETF Announcement list
>>> Cc:
>>> 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 ( 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 Chris Newman
>>> (Chris.Newman at
>>> Applications Area Advisor:
>>> Lisa Dusseault (lisa at
>>> Mailing List:
>>> General Discussion: p2pi at
>>> To Subscribe:
>>> Archive:
>>> 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 mailing list
>>  _______________________________________________
> p2pi mailing list
p2pi mailing list