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

["Narayanan, Vidya" <[e-mail]>]

All,
We have submitted a draft explaining the overall problem of peer selection - http://www.ietf.org/internet-drafts/draft-saumitra-alto-multi-ps-00.txt.  

Below are my suggested revisions to the charter based on arguments the draft puts forth (and based on emails exchanged over the last several days). 

Thanks,
Vidya

> -----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.
> 

Add: "Peer selection is also a problem that has many different applications in p2p systems - e.g., identifying the best peer to download content from, identifying the best super peer to contact in a system, using the best relay for NAT traversal, identifying the best next hop for a query based on several criteria (e.g., quality, reputation, semantic expertise, etc.), etc." 

> One of the advantages of P2P systems comes from redundancy in 
> resource availability.  This requires choosing among download 
> locations, 

s/download locations/a list of peers

> yet applications have at best incomplete 
> information about the topology of the network. 

s/incomplete information about the topology of the network/incomplete information to help the selection, e.g., 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

s/including/such as

> 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.
> 
> 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.
> 

I propose deleting "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.   

I suggest replacing this with Stanislav's suggestion: 

"A complete mechanism that enables clients to learn from the ALTO service information useful for peer selection".

> The WG does not require intermediaries between the ALTO
> server and the peer querying it.  

s/the ALTO server and the peer querying it/the communicating ALTO endpoints. 

> 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.
> 
> - 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.  

The above seems okay. 

> Other usages will be considered as extensions to the charter 
> once the work for the initial services has been completed.
> 

I think we should delete the sentence above.  

> - 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.
> 
> When the WG considers standardizing information that the ALTO 
> server could provide, the following criteria are important to 
> ensure real feasibility.
> 

In the context of standardization, I don't think we should be trying to evaluate the importance of any information.  The idea for us should be to standardize mechanisms to exchange peer selection related information.  The value of the actual information exchanged is very contextual and not for general evaluation.  

> - 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?
> - 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.  

The above again gets into our evaluation of what is important based on what we know today and is limiting. 

>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.  

s/applications and ALTO servers/ALTO endpoints

>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

s/servers/services

>(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.
> 
> 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
> 
_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi