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

["Daniel Park" <[e-mail]>]

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

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