Dear Salman,Thank you for forwarding a link to the paper to this mailing list. I attended Hotnets last week and thus heard the presentation of this paper. It sure is highly related. Does it make sense to also forward it to pprg?
This paper is valuable, but I do not feel that the paper provides much that we do not already know:
- Locality opportunities: for small swarms (the long tail) spanned across many networks, you may not have local opportunities. This should be true. Even here, I feel that we need to interpret the results carefully. For example, it uses iplane to map from IP to AS number. But some large ISP networks span multiple ASes and iplane is not aware of this. This appears to be not captured in the study. It is important to understand that locality opportunities depend on particular networks.
- Tradeoff between performance and locality: the paper argued that if you care for performance only, then some peers may suffer in performance. This is not a new result. For example, the foundation of the bandwidth matching algorithm (see the P4P paper) is to compute performance regions before optimizing for locality.
- Potential ISP conflict: this is also a well-known problem. The idea of adopting "my-Internet" view in ALTO is to allow ISPs to express differing views. Application algorithms such as bandwidth matching will provide check on extreme ISP views.
One way I read the paper is that it does not conflict with the ALTO effort. Instead, it reinforces the point of view that it should be done right.
Just some of my comments. Richard Salman Abdul Baset wrote:
A paper in this year's HotNets.http://conferences.sigcomm.org/hotnets/2009/papers/hotnets2009-final115.pdfThe paper argues that in practice the benefits of such design may be limited due to:(1) conflicting interests of ISP. -What is good for one ISP is not always good for the other ISP. (2) locality aware traffic may not work for long-tail content. I am curious what folks on this list have to say about this paper. Thanks Salman On Thu, 22 Oct 2009, rfc-editor at rfc-editor.org wrote:A new Request for Comments is now available in online RFC libraries. RFC 5693 Title: Application-Layer Traffic Optimization (ALTO) Problem Statement Author: J. Seedorf, E. Burger Status: Informational Date: October 2009 Mailbox: jan.seedorf at nw.neclab.eu, eburger at standardstrack.com Pages: 14 Characters: 34234 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-alto-problem-statement-04.txt URL: http://www.rfc-editor.org/rfc/rfc5693.txt Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices. This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. This memo provides information for the Internet community.This document is a product of the Application-Layer Traffic Optimization Working Group of the IETF.INFORMATIONAL: This memo provides information for the Internet community.It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-distFor searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ alto mailing list alto at ietf.org https://www.ietf.org/mailman/listinfo/alto_______________________________________________ alto mailing list alto at ietf.org https://www.ietf.org/mailman/listinfo/alto
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.