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.pdf
The 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, [email protected] 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: [email protected],
[email protected]
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-dist
For 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 [email protected]. 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
[email protected]
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
