RE: WG Review: Application-Layer Traffic Optimization (alto)
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of IESG Secretary Sent: Monday, October 06, 2008 1:36 PM To: IETF Announcement list Cc: [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) 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.
Re: WG Review: Application-Layer Traffic Optimization (alto)
Hi, On 2008-10-10, at 15:00, ext Marshall Eubanks wrote: 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. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and Does this mean that congestion is not an issue to consider ? If the closest peer to me was totally congested and had no available bandwidth, isn't that something that I would want to know ? I think the intent here is actually fine. ALTO attempts to improve the initial peer selection over simply choosing peers randomly by making some information available before this selection happens. The information provided through ALTO can't - in my opinion - include very detailed or timely load or congestion information, because I remain unconvinced that the ALTO system could actually obtain and maintain this information on the timescales it would need to. But there's other information that could be useful, such as some coarse-grained this peer is not totally on the other side of the planet-like information. Assuming that throughput and distance are by and large inversely proportional, preferring closer peers should often be better than choosing totally randomly. Other kinds of useful information could be talking to this peer doesn't count towards your bandwidth quota, etc. Now, once you actually establish and use a transport connection with the ALTO-recommended peer, you may well find that throughput is low. So you ditch the peer and try another one, which P2P systems already do. The intent here isn't that ALTO would pick the globally optimal peers for you, the intent is that it'll help an application reach a good set of peers a bit more quickly. Lars ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Application-Layer Traffic Optimization (alto)
On Mon, 6 Oct 2008, IESG Secretary wrote: - 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 believe this work could be useful and would provide an improvement over existing p2p usage and traffic management. I'd be more comfortable with this effort if a recharter (this is a rather lightweight process) was needed after finishing the problem statement and the requirements. It would also encourage that people actually put some serious work on those before diving into solutions :-) There are significant design issues that will come up in the protocols and I'd expect that it would be helpful if those had already been dealt with in the requirements phase. For example, the current req document has: REQ. 4: ALTO Clients MUST be able to find out where to send ALTO queries. .. and the charter lists DHCP option or SRV record as examples. Both of these have issues in certain contexts. For example, must this discovery mechanism work across unmodified NAT boxes? DHCP option doesn't; SRV record in many contexts doesn't either (or otherwise you'll end up with the same how to you discover the domain name under which you should look? problem). -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Application-Layer Traffic Optimization (alto)
I support this moving forward. My reading of the room in Dublin was that there was serious support for this and certainly a critical mass to move forward. Some comments in the charter below. This document clearly needs some more work. As a overall comment, I think it is premature to discuss ALTO servers and would keep the charter focused on describing the ALTO service. I do not see consensus at this moment as to a central service solution versus a distributed solution. Regards Marshall On Oct 6, 2008, at 4:35 PM, IESG Secretary wrote: 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 ([EMAIL PROTECTED]) 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. s/choose/choose the best peer or peers to exchange data with/ 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. 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 This is strange wording, as WG themselves are not protocols. More fundamentally, is this a requirement ? If so, it seems premature before a requirements draft is adopted. Saying The ALTO server here also seems limiting - is there a solution draft describing a server ? Others have already commented on central servers versus a distributed system, and to me the charter is not the place to make such decisions. I would remove this sentence entirely. 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. - 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. - In order to query the ALTO server, clients must first know one or more s/server/service/
RE: WG Review: Application-Layer Traffic Optimization (alto)
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of IESG Secretary Sent: Monday, October 06, 2008 1:36 PM To: IETF Announcement list Cc: [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) 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
Re: WG Review: Application-Layer Traffic Optimization (alto)
I tend to agree with Vidyan's comments. I think that addressing her comments regarding a service model instead of a server model is critical. While I too am surprised to see a WG review rather than a second bof, I would not personally object to the work if a reasonable process is followed in confirming we have sufficient consensus. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
