Re: [alto] Pitfalls for ISP-friendly P2P Design

["Y. Richard Yang" <[e-mail]>]

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