Subject: [alto] RFC 5693 on Application-Layer Traffic Optimization (ALTO) Problem Statement

From: [email-masked]
Date: Thu, 22 Oct 2009 16:44:05 -0700 (PDT)

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-masked], 
                    [email-masked]
        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-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

---

From: Salman Abdul Baset <[email-masked]>
Date: Fri, 23 Oct 2009 20:23:18 -0400 (EDT)

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-masked] wrote:

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>

---

From: Ping Pan <[email-masked]>
Date: Sun, 25 Oct 2009 15:30:46 -0700

Interesting. I agree that P2P traffic management differs among ISP's. Some
broadband operators may care much about the link cost, while the transit
providers have no such issue as long as the traffic is somewhat symmetrical.
But, I don't think P4P/ALTO is limited to solve the inter-domain traffic
issues only.

I find the following interesting: "...One might expect the median ratio of
average download rate to be 1; i.e., for each peer in a swarm, some nearby
peers will be slower, but others will faster. Instead, the median ratio is
0.15. This is because most BitTorrent peers from popular swarms in our
trace come from the United States, while most capacity comes from
comparatively high bandwidth peers in Europe...."

What does this mean? Does it imply that the content is in some remote
locations? No wonder the locality schemes won't work.

I wonder if the similar study can be done in other locations, such as China
and Europe...

Thanks!

- Ping

On Fri, Oct 23, 2009 at 5:23 PM, Salman Abdul Baset <[email-masked]>wrote:

>> For searching the RFC series, see
>> http://www.rfc-editor.org/rfcsearch.html.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 25 Oct 2009 22:13:22 -0400

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

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 27 Oct 2009 17:29:12 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Y. Richard Yang
Sent: Sunday, October 25, 2009 10:13 PM
To: Salman Abdul Baset
Cc: [email-masked]
Subject: Re: [alto] Pitfalls for ISP-friendly P2P Design

Dear Salman,

Richard

> A paper in this year's HotNets.
http://conferences.sigcomm.org/hotnets/2009/papers/hotnets2009-final115.
pdf

---

From: Arnaud Legout <[email-masked]>
Date: Wed, 28 Oct 2009 10:45:58 +0100

Hi,

I think it is very different to say that P2P locality does not work (or 
at least does not optimally work)
with current proposed solutions or current distribution of peers 
capacity, and that P2P locality does not work.
I agree that the former might be true on some scenarios, not the later.

My understanding of P2P locality is that it aims to reduce traffic on 
specific links, often referred to inter-ISP links, which is
misleading as it is so easy to come up with an ISP that don't want to 
reduce traffic on those links. There are probably as
many special cases as ISPs.
Improving download completion time of peers might be a nice side effect 
of P2P locality but it is not a target
(combining caches and P2P locality is an interesting way to also 
improved peers download completion time)

The P4P solution is very interesting from an architectural point of 
view, as it gives freedom to adapt locality
to the need of each ISP. However, the field test is
somewhat limited as it focuses on Comcast and a single large torrent (as 
described in the SIGCOMM paper). As Richard said
depending on the provisioning of peers you may observe different results 
in terms of download completion time. But, no matter the distribution of
peers bandwidth is, you still reduce traffic on the targeted links.

In the case of Ono, the authors never shown that Ono reduces inter-ISP 
traffic, but that it reduces the AS paths between peers.
This is very different. Instead, Ono focuses on improving peers download 
completion time. In that case, the distribution of peers bandwidth
really matters.

Coming back to the question "Does it make sense to do P2P locality?"
my answer is yes. In our work "pushing bittorrent locality to the limit" 
http://hal.inria.fr/inria-00343822/en/
we show measuring 200K torrents, 6M peers and 9K ASes that the potential 
reduction of traffic on inter-AS links
is 40% (more than a 4PB of data reduction on inter-AS links on a few 
hours) taking into account all those
tons of small torrents for which you cannot gain anything because you 
never have two peers within the same ISP.
One can still argue that inter-AS links is not always what you want to 
optimize,
as long as you want to reduce traffic on specific links, it will not 
change much our results.

We show that increasing or decreasing the peers download completion time 
will depend on where the bottlenecks are.
Therefore, the network bottlenecks will have a large impact, in 
particular when they are on the links on which
you want to reduce the traffic (this is the case we evaluated), but the 
access speed of peers will also matter.

Regards,
Arnaud.