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

["Woundy, Richard" <[e-mail]>]

Maybe I should comment as well, since the paper refers to "a measurement
node connected via Comcast", and since I am a co-author of RFC 5632
about Comcast's experiences with P4P.

First, I agree with Richard Yang's comments below. To clarify one of his
comments:

>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.

Comcast has 22 ASes: one for the backbone, and others for its regional
networks. (We hint at this in section 3.2 of RFC 5632.) So using the
"same AS" metric would localize traffic only within a relatively small
portion of the Comcast network.

Also, the Comcast backbone has interconnects with other service provider
backbones (obviously). The AS path length between two Comcast regional
networks may be the same as the AS path length between a Comcast
regional network and another ISP that is directly linked to the Comcast
network. So using the "shortest AS path" metric would blur the
distinction between intra-Comcast traffic and inter-provider traffic.

Second, part of the paper relies on "bandwidth measurements of more than
100,000 BitTorrent users collected from popular swarms in 2006." Using
that data, the paper concludes that "the total capacity of their peers
is greater under random matching than under shortest AS path matching"
because "most capacity comes from comparatively high bandwidth peers in
Europe".

We reached a different result in RFC 5632: download speed influenced by
P4P within Comcast improved from 255 kbps to 460+ kbps. Why the
difference between the Hotnets paper and RFC 5632? One likely reason is
that Comcast increased its typical customers' provisioned upstream
bandwidth from 384 kbps to 1 Mbps around June 2008. The Hotnets paper's
source of bandwidth measurements reflect 384 kbps upstream for Comcast
users; RFC 5632's testing reflect 1 Mbps upstream for Comcast users.

Third, I suppose it is possible that a 'tier 1 / strategic ISP' could
influence ALTO/P4P selection to favor customer ISPs, so as to provide a
monetary gain to the strategic ISP. But what would be the reaction of
the customer ISP? I am pretty sure they would figure out this is
happening. Maybe they might choose a different tier 1 provider, to lower
their own costs. Or they might complain to their national regulator
about how the situation is unfair. I doubt they would gladly pay more
money just to make the strategic ISP happier. But that's just my
opinion. :)

Fourth, the Hotnets paper used BitTorrent swarms (at least in some
cases) whereas RFC 5632 used Pando Network swarms, which may have had
different characteristics that make direct comparisons of optimization
difficult.

-- Rich

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Y. Richard Yang
Sent: Sunday, October 25, 2009 10:13 PM
To: Salman Abdul Baset
Cc: [e-mail]
Subject: Re: [alto] Pitfalls for ISP-friendly P2P Design

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

_______________________________________________
alto mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/alto