Application-Layer Traffic Optimization (ALTO) Problem Statement
Note: This ballot was opened for revision 04 and is now closed.
(Jari Arkko) (was Discuss) Yes
(Ron Bonica) Yes
(Lisa Dusseault) Yes
(Alexey Melnikov) Yes
(Ralph Droms) No Objection
(Lars Eggert) No Objection
Comment (2009-09-08 for -)
This isn't a blocking discuss, but please give these comments some serious consideration. The document touches on lots of important points, but misses one issue which I consider to be of key importance: what kinds of information can and will be provided using ALTO. Right now, the document is very generic on this, talking about "network-layer information" that will enable "better-than-random selection" of peers. I'd very much like the document to become more concrete, and discuss what kinds of network-layer information could reasonably be provided by an ALTO box, what kinds could be provided but are useless (because the peers can obtain it as easily by themselves) and what kinds of infomation is out of scope (for example, because it changes on timescales that make it impossible to provide via an out-of-band service like ALTO). INTRODUCTION, paragraph 14: > This document describes problems > related to improving traffic generated by peer-to-peer applications. > In particular, this document discusses issues which better-than- > random peer selection based on network-layer information may raise. Please be more clear in the abstract. This document discusses issues related to an information-sharing *service* to *enable* BTR peer selection; it's not about BTR selection or improving traffic itself (that will depend on whatever the applications using this service will do with the information.) Section 1.1., paragraph 4: > Recent studies [ACM.ispp2p] [WWW.p4p.overview] [ACM.ono] show a > possible solution to this problem. Internet Service Providers (ISP), > network operators or third parties can collect more reliable network > information. This information includes relevant information such as > topology or bandwidth available. Normally, such information changes > on a much longer time scale than information used for congestion > control on the transport layer. "Bandwidth available" to a specific peer and congestion are intrinsically linked. It's not accurate to say that one changes on slower timescales than the other. "Bandwidth available" information is likely something that an ALTO box cannot provide with useful precision. I'd pick a different example here. Section 1.1., paragraph 5: > This document gives the > problem statement of improving traffic generated by P2P applications > using information provided by a separate party. See my comment about the abstract. I believe that this paragraph doesn't quite capture what this document is about. Section 2., paragraph 2: > Application: A distributed communication system (e.g., file sharing) > that uses the ALTO service to improve its performance or quality > of experience while improving resource consumption in the > underlying network infrastructure. Applications may use the P2P > model to organize themselves, use the client-server model, or use > a hybrid of both (i.e., a mixture between the P2P model and the > client-server model). Up until know, the document was all about P2P. Now the documents talks about including hybrid applications, which presumably can degenerate into traditional client/server behavior. Please be very clear what the scope of ALTO is, P2P only or also client/server. If the latter, you need to make this clear in the abstract and introduction. Section 3., paragraph 1: > Network engineers have been facing the problem of traffic > optimization for a long time and have designed mechanisms like MPLS > [RFC3031] and DiffServ [RFC3260] to deal with it. The problem these > protocols address consists in finding (or setting) optimal routes for > packets traveling between specific source and destination addresses > and based on requirements such as low latency, high reliability, and > priority. Such solutions are usually implemented at the link and > network layers, and tend to be almost transparent. At best, > applications can only "mark" the traffic they generate with the > corresponding properties. This paragraph is confused on what DiffServ is. Section 3., paragraph 4: > Addressing the Application-Layer Traffic Optimization (ALTO) problem > means, on the one hand, deploying an ALTO service to provide > applications with information regarding the underlying network and, > on the other hand, enhancing applications in order to use such > information to perform better-than-random selection of the endpoints > they establish connections with. Again, please be clear about the scope. The ALTO WG is only chartered to look at some aspects of the former (providing a service to share network information - actually, only the query protocol towards that service). "Enhancing applications" (defining how applicaitons should or may use the information) is not in scope. Section 6., paragraph 2: > The approach proposed in this document asks P2P applications to > delegate a portion of their routing capability to third parties. > This gives the third party a significant role in P2P systems. I think this paragraph is highly inaccurate. ALTO is about sharing topology-related information with P2P peers, and not about delegation of functions.
(Pasi Eronen) No Objection
(Adrian Farrel) No Objection
Comment (2009-09-09 for -)
Thanks for this document. Possibly a bit of a terminology hicough... In Section 1 you have: > Peer-to-peer (P2P) applications, such as file sharing, real-time > communication, and live and on-demand media streaming use a > significant amount of Internet resources But in Section 2 > Resource: Content (such as a file or a chunk of a file), or a server > process (for example to relay a media stream or perform a > computation), which applications can access. In the ALTO context, > a resource is often available in several equivalent replicas. In > addition, different peers share these resources, often > simultaneously. Maybe you can solve this by adding another term to Section 2 to define "Internet Resource."
(Cullen Jennings) No Objection
(Tim Polk) (was No Record, Discuss) No Objection
Figure 1 implies that the Application protocol (****) runs between a Peer and the Resource Directory. Shouldn't the application protocol involve two Peers instead?
(Dan Romascanu) No Objection
Comment (2009-09-10 for -)
I am confused by section 4.5 and by DHTs being listed as part of the use cases. I percieve DHTs as a piece of technology that allow running P2P applications, so while it may be true that 'An ALTO solution can provide valuable information for DHT algorithms' on the other hand ALTO also is based on DHTs in order ro run on a P2P overlay.