Subject: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

From: Marshall Eubanks <[email-masked]>
Date: Wed, 3 Dec 2008 07:10:05 -0500

I thought this paper is relevant and did not see it in the ALTO or  
P2PI archives

http://arxiv.org/abs/0812.0581

 From the abstract :

  In this paper, we perform extensive experiments on a controlled  
environment with up to 10 000 peers to evaluate the impact of locality  
on inter-ISP links traffic and peers download completion time. In  
particular, we show that high locality values enable up to two orders  
of magnitude saving on inter-ISP links without any significant impact  
on peers download completion time.

------

This would be a very encouraging reduction of inter-ISP traffic if it  
could be approached in practice by what we are doing here.

This is not a simulation, but an experiment run on the Grid’5000  
network with 1700 nodes. Since the lead author is subscribed to the  
ALTO list, I am going to wonder publicly if it would be
possible (and sensible) to test any ALTO solution with this  
experimental setup.

Regards
Marshall

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

---

From: Maciej Wojciechowski <[email-masked]>
Date: Wed, 3 Dec 2008 13:55:19 +0100

On Dec 3, 2008, at 1:10 PM, Marshall Eubanks wrote:
>
> This would be a very encouraging reduction of inter-ISP traffic if  
> it could be approached in practice by what we are doing here.
>

The only thing that is different in this approach from the standard  
simulation is that a regular bittorrent client is used. The ISPs  
topology, seeders to leechers ratio, upload speeds and so on are  
purely artificial. The main problem with bittorrent simulations is not  
the inaccuracy of the simulated software but wrong assumptions about  
how the network really looks like. With respect to that, the  
abovementioned experiment is not much different from "simulating  
bittorrent with parameters that have unknown relation to real-world  
values".  Since much of the bittorrent behavior characteristics remain  
unknown (although many great measurement papers have been published)  
it is very hard to do credible simulations of protocol performance in  
changed conditions.

AFAIK the only locality-based p2p solution, that was deployed and  
tested in the real-world, with real bittorrent client, users, network  
etc. is Ono. The download speed turned out to be even a bit slower  
than for an unmodified client. (see figure 6a of the Ono SIGCOMM paper http://www.aqualab.cs.northwestern.edu/publications/DChoffnes08Sigcomm.pdf) 
. Locality, as measured by latency, is dropping down, but it does not  
boost download speed. I personally think that the actual download  
speed is bounded by last-mile, not by backbone speed or connection  
latency. Hence, if inter- and intradomain connections have the same  
speed, traffic locality cannot give significant performance boost.

--
  Maciej Wojciechowski
  Delft University of Technology
_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 03 Dec 2008 14:12:15 +0100

Maciej Wojciechowski wrote:
> etc. is Ono.

The P4P solution has been studied in the real world as well, with real
users and a proprietary client running a variant of the bittorrent protocol.

Results collected on the Comcast's network are discussed in
http://tools.ietf.org/id/draft-livingood-woundy-p4p-experiences.

-- 
Ciao,
Enrico

---

From: Maciej Wojciechowski <[email-masked]>
Date: Wed, 3 Dec 2008 14:44:08 +0100

Enrico,

> http://tools.ietf.org/id/draft-livingood-woundy-p4p-experiences.

Thanks for the link - I was unaware of this trial. Unfortunately, the  
draft discusses mostly the results and does not give much technical  
information on how the trial was exactly set up. One of the things  
that I'm missing is: how did the users actually find the content that  
was distributed in the trial?

Could you provide a link to a more in-depth explanation of the actual  
experiment? Based on the draft itself it is very hard for me to  
analyze applicability of the presented results.

Regards,
  Maciek Wojciechowski

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Dec 2008 05:49:11 -0800

On Dec 3, 2008, at 5:44 AM, Maciej Wojciechowski wrote:

> Thanks for the link - I was unaware of this trial. Unfortunately,  
> the draft discusses mostly the results and does not give much  
> technical information on how the trial was exactly set up. One of  
> the things that I'm missing is: how did the users actually find the  
> content that was distributed in the trial?

That was discussed in the talk itself.  The file was a ~20MB (so  
unfortunatly small) mandatory download IIRC, presumably an  
advertisement or similar as part of the Pando p2p system.

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 03 Dec 2008 14:57:18 +0100

> advertisement or similar as part of the Pando p2p system.

Slides, minutes and an audio recording of that talk are available at
http://trac.tools.ietf.org/wg/alto/trac/wiki (#6). I'm sure that if
other material about the experiment is publicly available, it will be
pointed out on this list shortly.

---

From: Rich Alimi <[email-masked]>
Date: Wed, 3 Dec 2008 09:13:42 -0500

Hi Maciej,

> analyze applicability of the presented results.

There was some discussion on the previous p2pi list that includes many of the 
details.  See:
  http://www.ietf.org/mail-archive/web/p2pi/current/msg00877.html
and the followup posts.

-- 
Richard Alimi
Department of Computer Science
Yale University

---

From: Arnaud Legout <[email-masked]>
Date: Wed, 03 Dec 2008 16:45:29 +0100

Hi,

> it is very hard to do credible simulations of protocol performance in 

You are right that you cannot obtain the best of each world.

However, it is plain wrong to claim that our results are equivalent to 
what would have been obtained
with simulations, or that our results do not bring any new significant 
insight compared to previous works.
I hope that a detailed reading of the paper will convince you. If this 
is not the case, I would be pleased to
discuss specific concerns.

As we explain in section 3.2, the results we obtained would have been 
hard, if not impossible, to obtain with simulations.
We show that the dynamics of the packets and of BitTorrent algorithms 
have a major impact on the inter-ISP traffic savings.
In particular, we found that an initial seed insufficiently provisioned 
may increase the inter-ISP traffic in case of locality.

Also, arguing that it is equivalent to run simulations than controlled 
experiments makes me feel going back ten years
ago. And yes, running a real BitTorrent client is one of the major 
difference compared to a simulation, but I don't
believe this difference can be discarded as a minor one.

If you have specific concerns on the methodology, I would be pleased to 
discuss them.

Running in the wild experiments is important, but it just gives one part 
of the picture. The other part can only be obtained
running controlled experiments, and varying well chosen parameters.
For instance, even if both Ono and P4P papers significantly improved the 
comprehension of P2P locality,
they do not answer all questions (and never claim to do so). However, 
there are still some fundamental problems to
explore, as explained in the introduction of our paper.

Regards,
Arnaud.

-- 
Arnaud Legout, Ph.D.

INRIA Sophia Antipolis - Planète  Phone : 00.33.4.92.38.78.15
2004 route des lucioles - BP 93   Fax   : 00.33.4.92.38.79.78
06902 Sophia Antipolis CEDEX      E-mail: [email-masked]
FRANCE                            Web   : http://www-sop.inria.fr/planete/Arnaud.Legout/index.html

---

From: Arnaud Legout <[email-masked]>
Date: Wed, 03 Dec 2008 16:49:34 +0100

Hi Marshall,

> possible (and sensible) to test any ALTO solution with this 

I am not sure what you mean by "test an ALTO solution", but for sure we 
can run (and are running) additional experiments
with real data.
Can you give a bit more details on which kind of experiments you would 
like to perform?

Regards,
Arnaud

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 3 Dec 2008 11:09:32 -0500

At some point in the future, we can update the draft
http://www.ietf.org/internet-drafts/draft-livingood-woundy-p4p-experienc
es-02.txt with additional relevant information on the test.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rich Alimi
Sent: Wednesday, December 03, 2008 9:14 AM
To: [email-masked]
Subject: Re: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

Hi Maciej,

> analyze applicability of the presented results.

There was some discussion on the previous p2pi list that includes many
of the 
details.  See:
  http://www.ietf.org/mail-archive/web/p2pi/current/msg00877.html
and the followup posts.

---

From: "Y. R. Yang" <[email-masked]>
Date: Wed, 3 Dec 2008 11:12:50 -0500 (EST)

Dear Maciek,

Thanks a lot for the pointer.

The P4P trials used Pando client, which is similar to standard BT client. 
In addition to the Pando client, in the past we have also tried other 
clients such as standard BT and Maze (a file sharing client). The standard 
BT experiments were done at PlanetLab, and the Maze experiment was done in 
China. Both are real experiments, although they are not comparable with 
the scale of the Pando experiment.

There is some detail about some of the experiments in a paper:
http://cs-www.cs.yale.edu/homes/yry/projects/p4p/p4p-sigcomm08.pdf

There is a thread about the setup of the Pando experiments (you may need 
to trace multiple emails):
http://www.ietf.org/mail-archive/web/p2pi/current/msg00884.html
http://www.ietf.org/mail-archive/web/p2pi/current/msg00886.html

A discussion of the P4P framework can be found at:
http://www.ietf.org/internet-drafts/draft-p4p-framework-00.txt

Some more slides about the implementations on the tracker side:
http://cs-www.cs.yale.edu/homes/yry/projects/p4p/p4p-implementation.ppt

To fully appreciate some detail of the results, you may need more details 
of the exact algorithms (e.g., the application optimization algorithm). We 
can give you pointer too.

Richard

On Wed, 3 Dec 2008, 2:44pm +0100, Maciej Wojciechowski wrote:

> information on how the trial was exactly set up. One of the things that 
> I'm missing is: how did the users actually find the content that was 
> distributed in the trial?
> 
> experiment? Based on the draft itself it is very hard for me to analyze 
> applicability of the presented results.
> 
> Regards,
> Maciek Wojciechowski

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 3 Dec 2008 11:14:12 -0500

Just an update on the minutes for the wiki,
http://www.ietf.org/proceedings/08nov/minutes/alto.html#comcast

"fine grained P4P model (11080 PIDs)" should really say "fine grained
P4P model (1180 PIDs)".

In fact, 1182 PIDs were used in the Comcast fine-grained model, per
section 5.1 of our draft.

-- rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Enrico Marocco
Sent: Wednesday, December 03, 2008 8:57 AM
To: Nicholas Weaver
Cc: [email-masked]
Subject: Re: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

---

From: "Y. R. Yang" <[email-masked]>
Date: Wed, 3 Dec 2008 12:18:07 -0500 (EST)

I found this discussion on simulation, controlled experiments, and real 
trials quite interesting. I found the paper Pushing BitTorrent Locality to 
the Limit quite interesting. Here are a few observations from our 
experiences:

- Current simulation techniques are not scalable to evaluate large-scale 
  P2P applications. We started with simulations and used quite powerful 
  clusters running at tens of thousands of CPU hours. Unfortunately, we 
  could simulate only to a few hundred clients. Even for a few hundred 
  clients, we could not afford packet level simulations. Thus a key issue 
  we encountered in simulation was how to determine the TCP throughput. We 
  used TCP throughput formula, but this is highly dependent on network 
  traffic dynamics, and thus so far have to be artificial.

- Controlled experiments are great.  One challenge of controlled 
  experiment is scalability: it is hard to get access to enough number of 
  clients to do repeated, controlled experiments (planetlab would give at 
  most a couple hundred usable clients). The authors of the paper did 
  quite well here.

  In addition to difficulties in clients, controlling network is 
  challenging: as observed by the paper, network background traffic can 
  have significant effects on the performance gain.  In particular, one 
  possible explanation that ISP efficiency (lower delay, or locality) and 
  application performance (i.e., file sharing download speed) may align 
  well is that TCP gives lower throughput to flows using more network 
  resources (i.e. delay, which measures length of link traversed).  Thus 
  optimizing network efficiency can at the same time improve application 
  performance (I am talking about the general cases; there are also 
  exceptional cases; there also can be other explanations such as faster 
  ramp-up time due to shorter TCP connection).  But the aforementioned 
  explanation assumes that there is contention in the network (i.e., 
  client end-host speed is not always the bottleneck).  We sure can use 
  controlled experiments to create contentions in the network and observe 
  the effects. If the results come back negative, we know that our 
  explanation is likely to be false. So in this sense, controlled 
  experiments can be of great value.

- Ultimately, it is trials with real users in the wild that answer the 
  basic question: can network information help network efficiency and 
  application performance? There are so many factors that can may 
  contribute to the results, and we may not be even aware of these factors 
  (e.g., implicit ISP traffic engineering factors).  Negative results or 
  extreme cases (like the paper did) from controlled experiments can be 
  particularly enlightening in helping us understand our problem better.
 
Just a few observations.

Richard

On Wed, 3 Dec 2008, 4:45pm +0100, Arnaud Legout wrote:

> > simulation is that a regular bittorrent client is used. The ISPs topology,
> > seeders to leechers ratio, upload speeds and so on are purely artificial.
> > The main problem with bittorrent simulations is not the inaccuracy of the
> > simulated software but wrong assumptions about how the network really looks
> > like. With respect to that, the abovementioned experiment is not much
> > different from "simulating bittorrent with parameters that have unknown
> > relation to real-world values".  Since much of the bittorrent behavior
> > characteristics remain unknown (although many great measurement papers have
> > been published) it is very hard to do credible simulations of protocol
> > performance in changed conditions.
> 
> what would have been obtained with simulations, or that our results do 
> not bring any new significant insight compared to previous works. I hope 
> that a detailed reading of the paper will convince you. If this is not 
> the case, I would be pleased to discuss specific concerns.
> 
> hard, if not impossible, to obtain with simulations. We show that the 
> dynamics of the packets and of BitTorrent algorithms have a major impact 
> on the inter-ISP traffic savings. In particular, we found that an 
> initial seed insufficiently provisioned may increase the inter-ISP 
> traffic in case of locality.
> 
> experiments makes me feel going back ten years ago. And yes, running a 
> real BitTorrent client is one of the major difference compared to a 
> simulation, but I don't believe this difference can be discarded as a 
> minor one.
>
> of the picture. The other part can only be obtained running controlled 
> experiments, and varying well chosen parameters. For instance, even if 
> both Ono and P4P papers significantly improved the comprehension of P2P 
> locality, they do not answer all questions (and never claim to do so). 
> However, there are still some fundamental problems to explore, as 
> explained in the introduction of our paper.
> 
> 
> Regards,
> Arnaud.
> 
> -- 
> Arnaud Legout, Ph.D.
> 
> FRANCE                            Web   :
> http://www-sop.inria.fr/planete/Arnaud.Legout/index.html
>

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Dec 2008 11:26:31 -0800

> the Limit quite interesting. Here are a few observations from our

The other factor is that you can also push the mental dial up to 100%  
localization:

With HTTP/server without caches:

N copies inbound on the transit link
0 copies outbound on the transit link
N copies through the ISP's internal cloud
N copies inbound on the last hop
0 copies outbound on the last hop

Performance is limited by the web server's upload bandwidth, the  
transit link, and the end user's download bandwidth

ISP cost is the transit link and the last hop

Content provider's cost is their transit cost (often much less than  
ISP transit cost)

With HTTP/server with distributed caches (akamai, CoralCache, inline  
HTTP cache) with perfection

1 copies inbound on the transit link
0 copies outbound on the transit link
N+1 copies through the ISP's internal cloud
N copies inbound on the last hop
0 copies outbound on the last hop

Performance is limited by the cache's bandwidth and the end user's  
download bandwidth

ISP's cost is just the last hop

Content provider's cost is the distributed cache's cost (which can be  
low or can be VERY expensive, I'm looking at you Akamai!)

With P2P, some localization, 1 < X < N

~X copies inbound on the transit link
~X copies outbound on the transit link
N+X copies through the ISP's internal cloud
N copies inbound on the last hop
N copies outbound on the last hop

Performance is limited by the end user's download bandwidth, the  
transit link, and the end user's upload bandwidth + ability to freeride

ISP's cost is both transit in and out, and the last hop in AND out.

Content provider's cost is very low (can go to near 0 if disallows  
most freeriding once the swarm is seeded)

With 100% localization and without caches:

1 copies inbound on the transit link
1 copies outbound on the transit link
N+1 copies through the ISP's internal cloud
N copies inbound on the last hop
N copies outbound on the last hop

Performance is limited by the end user's download bandwidth, the  
transit link, and the end user's upload bandwidth + ability to freeride

ISP's cost is the last hop in AND out

Content provider's cost is very low.

The interesting thing about localization is, even in the limit, it  
does not eliminate the transit on the last hop uplinks, and it does  
not eliminate the performance bottleneck of end user's upload  
bandwidth, or the dependence on freeriding if you want to download  
faster than the upload allows.

This is actually a big problem, as for many technologies (DSL, cable),  
the last mile is highly asymmetric and, for some (eg, Cable), the last  
hop uplink can often be a serious point of shared congestion and cost  
(adding bandwidth means killing TV channels!).   Thus for some  
significant networks, P2P is a huge magnification in aggregate cost  
even with perfect localization.

OTOH, if you add caches, then you get really GOOD behavior because,  
unlike HTTP caches, a failure in the cache doesn't cause a failure of  
the system (the cache is out of path), adding in such caches can be  
done without client changes (a cache is just another client node which  
allows freeriding ONLY to local nodes), while removing the uplink as a  
performance bottleneck (the cache can be placed in the ISP's internal  
cloud).  And for legitimate content, you don't have all the legal  
headaches you do on BitTorrent.

Thus:

With 100% localization and with caches:

1 copies inbound on the transit link
1 copies outbound on the transit link
N+1 copies through the ISP's internal clound
N copies inbound on the last hop
X < N copies outbound on the last hop

This suggests the following:

ANY localization discovery protocol must also include cache discovery,  
treating caches as special nodes which will only serve a set of  
subranges.

Any commercial P2P content distribution scheme should include caches.   
Such caches can be cheap & cheerful (a low power 1u server with 2x1TB  
disks and a GigE and a boot-from-CD to boot from net bootstrap  
startup, if you can't get this down to $1.5K, you're doing something  
wrong) but should be accounted for right from the start.

Simply because without caches, P2P costs ISPs a lot of money to save  
the content provider money, and you get everyone working at cross  
purposes.  And the customers suffer too, if you overload their  
outbound link.

But with caches, the costs radically shift the other way, so that P2P  
can save both the ISP AND content providers a lot of money.  At $.10/ 
GB, you only have to shift 15 TB out of the cache to pay for the cost  
of the cache.  If your cache is serving 100 Mbps, thats only 13 days  
of operation.  Even at a paltry 10 Mbps duty (so ~10 1Mbps customers)  
its still 130 days payback...

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Wed, 3 Dec 2008 14:33:14 -0500

I'm struck by this sentence:  "And for legitimate content, you don't
have all the legal headaches you do on BitTorrent."

I had thought this entire conversation was centered on distribution of
legitimate content.

Am I wrong?  If so, why?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicholas Weaver
Sent: Wednesday, December 03, 2008 2:27 PM
To: Y. R. Yang
Cc: Le Blond, Stevens ; Nicholas Weaver; Arnaud Legout; [email-masked]
Subject: Re: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

Thus:

---

From: Richard Bennett <[email-masked]>
Date: Wed, 03 Dec 2008 11:37:45 -0800

Good question.

DePriest, Greg (NBC Universal) wrote:

Am I wrong? If so, why?

-----Original Message-----

I found this discussion on simulation, controlled experiments, and
real
trials quite interesting. I found the paper Pushing BitTorrent
Locality to
the Limit quite interesting. Here are a few observations from our
experiences:

Thus:

---

From: Satish Raghunath <[email-masked]>
Date: Wed, 3 Dec 2008 11:43:51 -0800

Thanks for the link to your paper.

I had a few questions about the locality discussion in the paper.

Going by the discussion in Section 3.3.2 and Section 4.1, I get the
following impression. In the experiments, increased locality has the
effect of increased number of peers in the same ISP. That is, the
population of peers is somehow unaffiliated to ISPs and locality seems
to determine the number of ISPs per peer. Locality seems to be defined
in terms of the number of inter-ISP links and the number of peers per
ISP seem to change with that. Excerpt from 3.3.2:

    In all the experiments that evaluate the robustness of high
    locality values, for 8 inter-ISP connections the locality values
    range from 99% (for 100 peers and 10 ISPs) to 99.998% (for
    10 000 peers and 5 000 peers per ISP), and for 80 inter-ISP
    connections, the locality values range from 90% (for 100
    peers and 10 ISPs) to 99.98% (for 10 000 peers and 5 000
    peers per ISP).

Is my understanding right? Or did I misinterpret the text? 

I feel judging impact on download performance should ideally consider
the impact of lack of peers that participate in a swarm within the local
ISP. If I am an end-user, my concern would be more that I may not find
enough peers if a high degree of locality is enforced. I feel it is
important to add experiments that capture the problem of lack of peers
due to locality policy.

There were a few other minor questions that the paper may want to
clarify. There seem to be up to 100 bittorrent clients per node. Could a
'local download' result in two clients on the same node talking to each
other and could that lead to artificially low download times? 

The other question is about the bottleneck simulation (page 5, col 2).
This is somewhat different from a real n/w having throttling some place
in the network. The paper describes a per-node throttling mechanism. In
your experiment, if an ISP spans across nodes (lets say has 200 peers),
does the Linux 'tc' traffic controller policy make sure there is no
throttling between nodes that belong to the same ISP? This might again
complicate the read on download times for local downloads.

Thanks,
Satish

> Arnaud Legout
> Sent: Wednesday, December 03, 2008 7:50 AM
> To: Marshall Eubanks
> Cc: Le Blond, Stevens ; [email-masked]
> > This is not a simulation, but an experiment run on the Grid'5000

---

From: Laird Popkin <[email-masked]>
Date: Wed, 3 Dec 2008 15:01:20 -0500 (EST)

I agree.

For asymmetric consumer networks, data served by caches should reduce data served by consumer uplink, which is probably good for both the consumers and the network. Cache discovery is included in both P4P and (I believe) ALTO. The p2p caching companies PeerApp and Oversi are engaged in the P4P Working Group (and thus, at least indirectly, ALTO).

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Nicholas Weaver" <[email-masked]>
To: "Y. R. Yang" <[email-masked]>
Cc: "Le Blond, Stevens" <[email-masked]>, "Nicholas Weaver" <[email-masked]>, "Arnaud Legout" <[email-masked]>, [email-masked]
Sent: Wednesday, December 3, 2008 2:26:31 PM (GMT-0500) America/New_York
Subject: Re: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

Thus:

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Dec 2008 12:02:18 -0800

> I had thought this entire conversation was centered on distribution of

A localization service doesn't have to discriminate, and there some  
who want suitable privacy protections which would allow localization  
to work on BitTorrent regardless of the file being distributed.

> Am I wrong?  If so, why?

And its not just that.

Its that it actually is straightforward to make a BitTorrent cache  
today for an ISP:

You need to just do the following:

Have an IDS get a mirrored copy of the traffic, and look for tracker  
requests.

When an internal node contacts a tracker, have your cache contact the  
tracker to find local peers, and contact JUST those peers, exchange  
blocks with JUST those internal peers (so the cache is ONLY containing  
content that the internal nodes have fetched), and play some lying  
games (eg, tell one peer you have blocks belonging to the other peer,  
and vice-versa, esp using a large block of non-externally-routed  
addresses so you can seem like a whole BUNCH of peers to the internal  
BitTorrent clients).

This would work, would be straightforward to build (probably 2-3 man- 
weeks for a ugly prototype, a man-year or few for a good deployable  
product), would be out of path (so failures are non-damaging), but  
would be an invitation to a pile-of-DMCA-notices which, unless you are  
unable to automate, would cost so much more in person-time to handle  
than the cache would save in traffic.

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Wed, 3 Dec 2008 16:15:01 -0500

You note that "A localization service doesn't have to discriminate
[between legit and illegit P2P]..."

I don't understand why it wouldn't.  

What's the point of facilitating the illegal distribution of copyrighted
content?  

And how would one justify that?

-----Original Message-----
From: Nicholas Weaver [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2008 3:02 PM
To: DePriest, Greg (NBC Universal)
Cc: Nicholas Weaver; Y. R. Yang; Le Blond, Stevens ; Arnaud Legout;
[email-masked]; Craig Seidel
Subject: Re: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

And its not just that.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Dec 2008 13:36:39 -0800

> And how would one justify that?

Under the same justification that you allow BitTorrent at all: You  
DON'T know that it is copyrighted, it could be Linux ISOs, with enough  
probability that you can't just block the protocol and you can't sue  
BitTorrent Inc into submission under the Napster and related methods.

Or that you allow HTTP traffic, after all, that could be copyrighted  
material, kiddie porn, or other bad content.

It is not the responsibility of the network to police content, and a  
localization service doesn't actually have to know what it is  
localizing, so it is not in a position to police content one way or  
the other.

EG, ask localization service "Who else is accessing 512b-random-ID  
SHA-512 file descriptor", and the localization service has no notion  
what the resource is, just a list of who's accessing it.  Its in many  
ways easier to make a localization service which is agnostic.

---

From: Richard Bennett <[email-masked]>
Date: Wed, 03 Dec 2008 13:42:39 -0800

It strikes me that the discovery of illegal content is a local policy 
decision. There are jurisdictions that require it and those that forbid 
it. Perhaps ALTO needs to support a policy option that allows content 
descriptors to be queried, blocked, or redirected in the interest of 
local laws and regulations.

I don't want to spoil anybody's fun, of course.

RB

-- 
Richard Bennett

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 03 Dec 2008 16:01:31 -0600

> local laws and regulations.

ALTO's charter does not consider the issue of dealing with
legality of content to be in scope of the working group
(http://www.ietf.org/html.charters/alto-charter.html).

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Wed, 3 Dec 2008 17:02:42 -0500

That seems like a constructive suggestion.  Thank you.

I do have one question regarding policies.

Why is protecting privacy a requirement and protecting copyrighted
content a policy?

-----Original Message-----
From: Richard Bennett [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2008 4:43 PM
To: Nicholas Weaver
Cc: DePriest, Greg (NBC Universal); [email-masked]; Arnaud Legout; Paul
Jessop; Craig Seidel; Le Blond, Stevens 
Subject: Re: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

RB

-- 
Richard Bennett

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Dec 2008 14:33:58 -0800

On Dec 3, 2008, at 2:19 PM, Paul Jessop wrote:
> But I look forward to the answer to the question you ask: why is
> protecting privacy a requirement and protecting copyrighted content a
> policy?

There is a large amount of content that people view which is  
embarrasing but not illegal.

EG, suppose you use a P2P system to view a video about, say, girls who  
are unnaturally attracted to sheep.  Filmed where it was legal, and  
you're watching it in San Francisco (where community standards are  
uhh, interesting...)

Should I or someone else be able to query a localization server for  
"All those into NSFW ovine videos?"  Obviously not.

The problem is, however, you CAN'T actually have privacy preserving to  
the degree some would want.

Someone within the network can always see who else is viewing that  
file if they can get the hashkey for that file, in pretty much any P2P  
system at all, and the localization server may help in this process  
but isn't essential for this process.

If the model is "anyone can add a hashkey" to the system, you will  
have pirated material, and if the keys are identified by the content  
owner, the DMCA or similar should be reasonable to take them down  
(assuming you want to play whak-a-mole on localization servers which,  
if removed, would not affect people's ability to get the pirated  
content).

But you also have significant noninfringing uses which need the  
"anyone can add a key" model.

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Wed, 3 Dec 2008 18:02:21 -0500

a)  This helps but doesn't quite join the argument.

You state "There is a large amount of content that people view which is
embarrassing but not illegal."

It's not that the content is "embarrassing but not illegal."  

Rather, it's that it's being expeditiously and efficiently distributed,
thanks to ALTO, without the content owner's permission (which I assume
is either the girls or the sheep).  

It is not difficult to look out for their interests.  Why wouldn't we?

b)  Not to sidetrack my central point (above), but it seems to me it's a
bit of a hollow exercise to call for privacy while noting "Someone
within the network can always see who else is viewing that file if they
can get the hashkey for that file..."  

I'm not a privacy expert.  Am I missing something?
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicholas Weaver
Sent: Wednesday, December 03, 2008 5:34 PM
To: Paul Jessop
Cc: Le Blond, Stevens ; DePriest, Greg (NBC Universal); [email-masked];
Arnaud Legout; Paul Jessop; Craig Seidel; Nicholas Weaver
Subject: Re: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

---

From: Richard Bennett <[email-masked]>
Date: Wed, 03 Dec 2008 15:10:43 -0800

When you join the swarm for a given piece of content and you can see the 
others in the swarm. This is fundamental for P2P file transfer and 
certain other purposes. There are systems that cloak the swarm's IPs, 
used almost exclusively by pirates. You probably knew that.

RB

-- 
Richard Bennett

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Wed, 3 Dec 2008 18:16:10 -0500

There are a number of companies that can demonstrate working technical
solutions that identify copyrighted content.  It is not difficult.

Item three at http://www.ugcprinciples.com/ references how content
identification technology is now being used by user-generated content
sites to respect copyrights.

-----Original Message-----
From: James Seng [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2008 5:41 PM
To: DePriest, Greg (NBC Universal)
Cc: Richard Bennett; Nicholas Weaver; Paul Jessop; Craig Seidel; Le
Blond, Stevens; [email-masked]; Arnaud Legout
Subject: Re: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

Good point.

My view is that one can be reasonably solved technically without human  
intervention and one is not.

I love to see a working technical solution that can identify copyright  
content.

Sent from my iPhone

On Dec 4, 2008, at 6:02 AM, "DePriest, Greg (NBC Universal)"
<[email-masked] 
 > wrote:

---

From: "James Seng" <[email-masked]>
Date: Thu, 4 Dec 2008 08:15:16 +0800

Good point.

I love to see a working scalable technical solution that can identify
copyright content in an encrypted stream.

-James Seng

---

From: "James Seng" <[email-masked]>
Date: Thu, 4 Dec 2008 08:31:49 +0800

Technically it is possible to demonstrate a technology that can
identify the video, via watermarking, fingerprinting, sampling, etc
etc, to make reasonable guess & match of the video content. Facial,
voice recognition technology are also well-established that it can be
reasonable adapted.

Deploying these technology in a network protocol however is a
different set of problem however, particularly the computation and the
data set. These technology is sufficient complex that it is not
possible for the networking devices to handle.

This means it would rely on a third party, somewhat centralized system
to do the computation, which would work, except IETF, in general, have
very challenging difficulties to reach rough consensus on a
centralized system*. And you have this other nasty problem called
"scaling" to deal with.

I haven't follow on the technology development in the video matching
field to say with confident how accurate it would be but for
discussion, lets say 70-80% accuracy assuming no false positive,
similar for voice recognition, language translation, spam
identification etc. It is the same reasons why these technologies was
never able to be fully adopted within IETF protocol.

* Certain exceptions are made if it involved IANA, but even so, it is
difficult. And in this particularly case, I doubt IANA is keen to host
"fingerprints" of all the video content.

-James Seng

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Dec 2008 18:44:31 -0800

> It is not difficult to look out for their interests.  Why wouldn't we?

Why does it have to be without the content owner's permission?

If I'm in charge of NSFWing-sheep.com, where I'm distributing large  
video files in HD with all the ovine details, P2P swarms are very  
attractive due to their high bandwidth and the large interest for such  
things, because it shifts cost away from me and onto the ISPs. [1]

And I can maintain all my billing controls through access to the  
tracker to only logged-in customers.  So only those participating in  
the BitTorrent swarm are the ones who have permission.

This is the entire thrust behind the commercialization of BitTorrent  
and Amazon's S3 support for BitTorrent: it allows lower cost (to the  
content provider) distribution of large, popular files.

In such an environment, the ovine afficianatos can find out each other  
(thats the natural limit of P2P), but if someone can't access my  
tracker, someone can't find out who else is interested.

It is natural to desire that any localization scheme have the same  
property: only swarm participants should know BOTH the file AND the  
participants.  After all, the ISP can also know the participants  
thanks to traffic analysis, but with encryption, can't know the file  
contents.

And if the design is the tracker provides a random NONCE as a swarm ID  
for purposes of localization, with the ALTO servers only telling peers  
with the nonce about other peers with the same nonce, you have the  
best-case privacy property:

The Alto server can only reveal participants to other participants  
when both know the nonce, and the ALTO server doesn't know the file,  
just the participants.

And you want arbitrary content hosts to be able to create localization  
Nonces (no access control).  You don't register with a central  
authority to put up a web page, why should you register with a central  
authority to improve P2P behavior?

> I'm not a privacy expert.  Am I missing something?

The key privacy constraint is that someone NOT participating in a P2P  
swarm should not be able to query an Alto server to know who is  
participating in that P2P swarm, and that the alto server itself  
should not know what the file swarm is about unless it is specifically  
notified.

After all, do you want the ISP's localization server to be told about  
your taste in sheep?

Yet if the legitimate content provider HAS accessed the swarm, they  
CAN identify the participants anyway, so an Alto server doesn't help.   
And should they DMCA the nonce it doesn't actually do any good: part  
of the model is localization is optional, if it fails, a P2P system  
still works.

I am NOT a fan of BitTorrent and its primary use of content piracy.   
But there are real reasons why, for legitimate content, Alto needs the  
privacy-preserving properties.

[1] And if I was involved with Hulu, I'd be talking very VERY  
seriously with Adobe about building some cache-aware P2P extensions  
into Flash (or Microsoft into Silverlight).  Thats some serious  
bandwidth bill through Akamai you're dealing with, and it would be  
nice to have the infrastructure in place to cut out that middle-mad.

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 3 Dec 2008 21:58:47 -0500

Well, I personally think it would be really cool if any proposed ALTO  
solution had experimental
validation behind it.

I have been dubious about NS2 type simulations in these cases, and was  
pleased to see what you are doing.

Regards
Marshall

On Dec 3, 2008, at 10:49 AM, Arnaud Legout wrote:

> I am not sure what you mean by "test an ALTO solution", but for sure  
> we can run (and are running) additional experiments
> with real data.
> Can you give a bit more details on which kind of experiments you  
> would like to perform?
>
> Regards,
> Arnaud
>
>

---

From: Fabio Hecht <[email-masked]>
Date: Thu, 04 Dec 2008 10:20:52 +0100

Don't forget to take into account that what is illegal where you live
may be perfectly legal somewhere else, and vice versa. I think it is
clearly declared out of scope of the charter for a very good reason.

Regards Fabio

-- 
Fabio Hecht

University of Zurich - Department of Informatics (IfI)
Binzmühlestrasse 14 CH-8050 Zürich, Switzerland
Ph.: +41 44 6357129 / 6350892  Fax: +41 44 6356809
VoIP sip:[email-masked]

---

From: Richard Bennett <[email-masked]>
Date: Thu, 04 Dec 2008 01:39:44 -0800

That's not an unusual situation for globally-deployed network systems. 
Wi-Fi uses unlicensed radio channels in several regulatory domains that 
don't exactly line up with each other in terms of the frequencies and 
power levels that are permitted. The relevant standards body, IEEE 
802.11, didn't define channels and power levels as "out of scope", they 
embraced the problem and permitted the appropriate regulations to be 
plugged-in to standards-conformant systems at run time.

It's not impossible, or even especially difficult, to create standards 
that include the application of local variations. There are all sorts of 
legal restrictions on content and privacy around the world, and I'd 
rather take the adult approach and make the ALTO protocol capable of 
conforming to law and regulation by design rather than through some 
external workaround.

Take that for what it's worth, I'm still coming up to speed on this effort.

RB

Fabio Hecht wrote:
>>>>> What's the point of facilitating the illegal distribution of
>>>>>           
>>> copyrighted
>>>       
>>>>> content?
>>>>>

---

From: Fabio Hecht <[email-masked]>
Date: Thu, 04 Dec 2008 11:13:38 +0100

I understand, but I believe that will lead to most users not using ALTO.

Regards Fabio

-- 
Fabio Hecht

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Thu, 4 Dec 2008 05:25:41 -0500

Wouldn't a standard meeting the legitimate needs of all parties stand a much greater chance of success?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fabio Hecht
Sent: Thursday, December 04, 2008 5:14 AM
To: Richard Bennett
Cc: alto
Subject: Re: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

Regards Fabio

-- 
Fabio Hecht

---

From: "James Seng" <[email-masked]>
Date: Thu, 4 Dec 2008 18:39:10 +0800

Depends how you define "success". Commercial success, perhaps so (Hulu
has definitely show it can be done very successfully).

But In IETF, we do "running codes". A solution that requires using a
proprietary technology that does not allow it to be widely adopted,
regardless of its commercial success, is not successful by IETF
standard.

ps: I am not against "protecting copyrighted content" but that can
deal with in other venue, not embedded into internet protocols.

-James Seng

---

From: Victor Grishchenko <[email-masked]>
Date: Thu, 4 Dec 2008 12:20:36 +0100

On Dec 3, 2008, at 8:26 PM, Nicholas Weaver wrote:
> This is actually a big problem, as for many technologies (DSL,  
> cable), the last mile is highly asymmetric and, for some (eg,  
> Cable), the last hop uplink can often be a serious point of shared  
> congestion and cost (adding bandwidth means killing TV channels!).    
> Thus for some significant networks, P2P is a huge magnification in  
> aggregate cost even with perfect localization.

Is it a coincidence that the technologies listed are, in fact, legacy  
mediums fixed to also do the internet?

> Any commercial P2P content distribution scheme should include  
> caches.  Such caches can be cheap & cheerful (a low power 1u server  
> with 2x1TB disks and a GigE and a boot-from-CD to boot from net  
> bootstrap startup, if you can't get this down to $1.5K, you're doing  
> something wrong) but should be accounted for right from the start.

It is a good fix to legacy infrastructure, yes. I guess, such caches  
might function quite transparently, as "super-peers".

-- 

	V

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Thu, 4 Dec 2008 07:50:17 -0500

I appreciate your reasonableness and need to note two things:  I lack the skills to define where a solution goes and I'm not suggesting the use of a proprietary technology.  

I am suggesting that unless we recognize (and address) the root of the congestion problem ALTO seeks to solve, ALTO's effectiveness is likely to be compromised from the start.  

Does that make sense?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James Seng
Sent: Thursday, December 04, 2008 5:39 AM
To: DePriest, Greg (NBC Universal)
Cc: Fabio Hecht; Richard Bennett; alto
Subject: Re: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

-James Seng

---

From: Maciej Wojciechowski <[email-masked]>
Date: Thu, 4 Dec 2008 14:00:40 +0100

On Dec 4, 2008, at 1:50 PM, DePriest, Greg (NBC Universal) wrote:
>
> I am suggesting that unless we recognize (and address) the root of  
> the congestion problem ALTO seeks to solve, ALTO's effectiveness is  
> likely to be compromised from the start.
>
> Does that make sense?
>

I think I'm a bit lost here. What does congestion have to do with  
copyright?

Regards,
Maciek Wojciechowski

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Thu, 4 Dec 2008 08:02:18 -0500

Good question.

There is no doubt current congestion is caused by distribution of
copyrighted content without the owners' permission.

Stated another way, NBC Universal's content is causing your congestion
problem and we'd like to help you solve it.

-----Original Message-----
From: Maciej Wojciechowski [mailto:[email-masked]] 
Sent: Thursday, December 04, 2008 7:57 AM
To: DePriest, Greg (NBC Universal)
Cc: James Seng; Craig Seidel; alto
Subject: Re: [alto] Paper on "Pushing BitTorrent Locality to the Limit"

Regards,
  Maciek Wojciechowski

---

From: Maciej Wojciechowski <[email-masked]>
Date: Thu, 4 Dec 2008 14:10:45 +0100

Arnaud,

On Dec 3, 2008, at 4:45 PM, Arnaud Legout wrote:
> However, it is plain wrong to claim that our results are equivalent  
> to what would have been obtained
> with simulations, or that our results do not bring any new  
> significant insight compared to previous works.
> I hope that a detailed reading of the paper will convince you. If  
> this is not the case, I would be pleased to
> As we explain in section 3.2, the results we obtained would have  
> been hard, if not impossible, to obtain with simulations.
> We show that the dynamics of the packets and of BitTorrent  
> algorithms have a major impact on the inter-ISP traffic savings.
> In particular, we found that an initial seed insufficiently  
> provisioned may increase the inter-ISP traffic in case of locality.
>
> Also, arguing that it is equivalent to run simulations than  
> controlled experiments makes me feel going back ten years
> If you have specific concerns on the methodology, I would be pleased  
> to discuss them.
>
> Running in the wild experiments is important, but it just gives one  
> part of the picture. The other part can only be obtained
> For instance, even if both Ono and P4P papers significantly improved  
> the comprehension of P2P locality,
> they do not answer all questions (and never claim to do so).  
> However, there are still some fundamental problems to

You are right, that a control experiment like yours can be very  
helpful in getting a better understanding of what is in fact going on.

I'm talking about Marshall's sentence from first post in this thread  
"This would be a very encouraging reduction of inter-ISP traffic if it  
could be approached in practice by what we are doing here". I think  
that if those results could be reproduced it would be great. I'm just  
highly doubtful that they can.

While simulations are very important in learning how complex and  
distributed systems work, in many cases they aren't very good at  
predicting how they would work.

Few examples from your work:
- the content size is 100MB
- the upload speed is 20kB/s or 100kB/s
- you look at two different topologies: full mesh and two-tier topology
- very small inter ISP links ("We vary the inter-ISP link capacity  
from 40kB/s to 2 000kB/s.")

Where did those values/configurations come from? Do you have any kind  
of proof that this is how torrent network actually looks like? Why is  
it 20kB/s and not 200kB/s or 1037kB/s? Why 100MB and not 257MB or  
2057MB? I have never heard of inter ISP link with 2000kB/s capacity  
(not mentioning the 40kB/s). I have heard about 10Gbit/s ones though.  
I cannot see them anywhere in your work...

Few things that in my opinion are significant and are not taken into  
consideration:
- other web activities (like web browsing, gaming, ftp, youtube,...)  
of the users
- setting arbitrary max download and max upload speeds
- downloading many torrents at the same time
- vast part of real-world users are hidden behind a NAT
- users with very big symmetric links (e.g. 100Mbit) that are seeding  
much more than downloading. Yes, there are such users...
- and many, many more.

Honestly, there are hundreds of factors, many of them very complex. Do  
you really want to argue that the simplified model you presented is  
good enough to reason about bittorent behavior?

I want one thing to be clear: I really like your paper, as a study  
work that can help us understand the problem better. But with all due  
respect, I simply cannot agree that this is a valid bittorrent model.  
Hence, I don't see why those results would give us knowledge about how  
the deployed ALTO system would perform in the real-world.

Regards,
  Maciek Wojciechowski

---

From: "DOLGANOW Andrew" <[email-masked]>
Date: Thu, 4 Dec 2008 07:53:04 -0600

We should focus on solving the technical problem of optimizing P2P the
ALTO was created for. I do not believe that ALTO solution should try to
enforce local laws pertaining to P2P traffic at this point. There are
other solutions on the market that deal with this space today.

Andrew 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Richard Bennett
> Cc: Le Blond, Stevens ; DePriest,Greg (NBC Universal); Arnaud 
> Legout; [email-masked]; Paul Jessop; Craig Seidel
> It strikes me that the discovery of illegal content is a 
> local policy decision. There are jurisdictions that require 
> it and those that forbid it. Perhaps ALTO needs to support a 
> policy option that allows content descriptors to be queried, 
> blocked, or redirected in the interest of local laws and regulations.
> 
> >> copyrighted content?

---

From: Stevens Le Blond <[email-masked]>
Date: Thu, 04 Dec 2008 14:55:19 +0100

Dear Satish,

Thank you for your interest in our paper. I will  try to answer your
questions, please do not hesitate to tell me if something is still
unclear afterward.

> Is my understanding right? Or did I misinterpret the text? 

Let me rephrase this to make sure we understand each other.

As we define locality as the percentage of cross-ISP connections (see
Section 3.1) and the number of connections per peer is fixed (i.e., 80),
if we increase the number of peers in an ISP, the number of inter-ISP
connections in that ISP increases as well. To keep the number of
inter-ISP connections constant while we vary the torrent size and the
number of peers per ISP, we vary the locality value. For this reason, we
consider 2 fixed numbers of inter-ISP connections (i.e., 8 and 80) in
Section 5.

> important to add experiments that capture the problem of lack of peers

As you have noticed, there is a trade off here: If I am an end-user my
concern is to get good performances but if I am an ISP, my concern is to
reduce my bill. At one extreme, if there is only one user active for a
file in one ISP, there is no locality to be exploited. What to do in
that case, e.g., delay the transfer or not, is outside of the scope of
our paper. Our paper relies on findings from previous works that showed
that there is locality to be exploited.

However, note that we have experimented with as few as 10 peers per ISP
in Section 5.1 and showed that even in that case, we can save up to 54%
of inter-ISP traffic with absolutely no performance penalty as compared
to BitTorrent.

> other and could that lead to artificially low download times? 

Yes, two peers on the same node can talk to each.

I'm not sure why that may lead to slower download times as all peers
read and write on some disk with a limited speed. The pieces must be
read by a first peer, and then written by a second peer. That those two
peers be located on the same node or not, the load is the same globally.

That said, you are right that we have to be careful with the load on the
nodes for the experiments to be relevant. However, we discuss this issue
in Section 3.2.1 (last paragraph), and are actually quite conservative
in the number of clients that we run on each node.

> complicate the read on download times for local downloads.

In those experiments we run 1,000 clients on 10 physical nodes with a
topology of 10 ISPs (one node per ISP). Hence, no ISP spans across
nodes. You can read Section 5.3, Fig. 7, and Fig. 8 for more details. We
could have made this point clearer, thank you for pointing that out.

Thank you very much for your comments.

Best regards,
Stevens Le Blond

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 4 Dec 2008 06:22:07 -0800

> problem and we'd like to help you solve it.

If that is your goal, ALTO is no place to effect it.

The only possibility I can think of that would actually work is DMCA  
"Takedown Graphs", but the notion of one of very many third parties  
(after all, there are a lot of distinct content owners) being able to  
tell my ISP to block communication between a set of users is frankly,  
horribly distastful, and the risks of abuse of such a mechanism would  
be catastrophic.

---

From: James Seng <[email-masked]>
Date: Thu, 4 Dec 2008 06:40:43 +0800

Good point.

Sent from my iPhone

On Dec 4, 2008, at 6:02 AM, "DePriest, Greg (NBC Universal)" <[email-masked]

---

From: Arnaud Legout <[email-masked]>
Date: Thu, 04 Dec 2008 18:44:12 +0100

Hi Maciej,

> highly doubtful that they can.

We do not intend to overstate our results. We are simply performing a 
study intended to
give a first answer to the three questions we present in the introduction:
-How far can we push locality?
-What is, at the scale of a torrent, the reduction of traffic that can 
be achieved with locality?
-Can locality significantly deteriorate the peers experience?

I don't know what you mean by reproducibility. If you mean that we will 
not find in the Internet
a torrent with the exact same characteristics than the ones we have 
evaluated, you are right.
However, our results show that we can push locality further than what 
was done up to now
with a great reduction on the inter-ISP traffic. Claiming that this 
reduction will be 2 orders of magnitude
on a real torrent, or 1.75 or whatever you want would be pointless. It 
will be much better
than what you can obtain with the locality values considered up to now 
(around 80%), without a
negative impact on peers download completion time. This is the important
point.

> like? Why is it 20kB/s and not 200kB/s or 1037kB/s? Why 100MB and not 
> 257MB or 2057MB? I have never heard of inter ISP link with 2000kB/s 
> capacity (not mentioning the 40kB/s). I have heard about 10Gbit/s ones 
> though. I cannot see them anywhere in your work...
>

This is exactly the point. There are so many factors that you cannot 
test everything.
Either you measure real torrents and traffic, but it is only relevant 
for what you have measured at that moment,
and you will never understand this way the impact of some specific 
parameters. We did that for BT in another
context (see our IMC'2006 study)
and know that this is just one part of the big picture that allows you 
to understand what is going on.

Or, you make controlled experiments varying one parameter at a time. The 
question here is how you chose the
fixed parameters and the range of what you vary. This is based on 
experience and understanding you got from
in the wild experiments, and related work.
We are quite confident that our choices are relevant and allow us to 
show what we wanted to show.
But of course it is always possible to make different choices and to 
compare different approaches.
This is why research is great.

> the deployed ALTO system would perform in the real-world.

All depends on what you mean by knowledge. Don't attribute to our study 
a larger scope than what we described.
Our study simply says that if you increase the locality up to very high 
values
then the inter-ISP traffic will be lower without negative impact on 
end-users.
Forget about absolute values, they are only there to compare different 
experiments in the context of our study.
If you claim that we haven't shown that it makes sense to consider high 
locality values, then I have to disagree.

Regards,
Arnaud.

---

From: Satish Raghunath <[email-masked]>
Date: Thu, 4 Dec 2008 10:34:24 -0800

Ok, I think I understand the model better. I see your point that there
is no locality to be exploited when there are too few peers. But I think
one interesting scenario is as follows especially considering that you
now have a powerful testbed to get controlled results. Fix the mapping
of peers to ISPs using some distribution (preferably empirically
derived) and then measure the effect of locality. I feel such an
experiment is still desirable since an administrator who would want to
deploy locality would likely not have the choice of using it only when
it is feasible (rather it is likely to be a simple blanket policy across
all torrents and for all ASes under his/her control).

> From: Stevens Le Blond [mailto:[email-masked]]
> Sent: Thursday, December 04, 2008 5:55 AM
> To: Satish Raghunath
> Cc: Arnaud Legout; Marshall Eubanks; [email-masked]

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 4 Dec 2008 14:57:33 -0500

I agree that the overall localization solution contemplated by the IETF
probably should include cache discovery and usage. (In particular, the
overall solution must not preclude the inclusion of caching, although
caching may or may not be part of any particular deployment.)

I'm not yet 100% convinced that the localization discovery protocol and
the cache discovery protocol need to be the *same* protocol. But to be
fair, I changed my mind on this subject just IETF Dublin...

-- Rich

-----Original Message-----

Thus:

---

From: Maciej Wojciechowski <[email-masked]>
Date: Fri, 5 Dec 2008 11:19:40 +0100

Hi Arnaud,

I think we both made our points clearly and I think we can both agree  
that we could continue this discussion infinitely.
Since this group is not the right place to discuss particular  
scientific papers in details, I suggest we stop right now.

Regards,
  Maciek Wojciechowski

On Dec 4, 2008, at 6:44 PM, Arnaud Legout wrote:

>> I'm talking about Marshall's sentence from first post in this  
>> thread "This would be a very encouraging reduction of inter-ISP  
>> traffic if it could be approached in practice by what we are doing  
>> here". I think that if those results could be reproduced it would  
>> be great. I'm just highly doubtful that they can.
>
> We do not intend to overstate our results. We are simply performing  
> a study intended to
> -What is, at the scale of a torrent, the reduction of traffic that  
> can be achieved with locality?
> I don't know what you mean by reproducibility. If you mean that we  
> will not find in the Internet
> However, our results show that we can push locality further than  
> what was done up to now
> on a real torrent, or 1.75 or whatever you want would be pointless.  
> It will be much better
> than what you can obtain with the locality values considered up to  
> now (around 80%), without a
>> like? Why is it 20kB/s and not 200kB/s or 1037kB/s? Why 100MB and  
>> not 257MB or 2057MB? I have never heard of inter ISP link with  
>> 2000kB/s capacity (not mentioning the 40kB/s). I have heard about  
>> 10Gbit/s ones though. I cannot see them anywhere in your work...
>>
>> Few things that in my opinion are significant and are not taken  
>> into consideration:
>> - other web activities (like web browsing, gaming, ftp,  
>> youtube,...) of the users
>> - users with very big symmetric links (e.g. 100Mbit) that are  
>> seeding much more than downloading. Yes, there are such users...
>> - and many, many more.
>>
>> Honestly, there are hundreds of factors, many of them very complex.  
>> Do you really want to argue that the simplified model you presented  
>> is good enough to reason about bittorent behavior?
>
> Either you measure real torrents and traffic, but it is only  
> relevant for what you have measured at that moment,
> and know that this is just one part of the big picture that allows  
> you to understand what is going on.
>
> Or, you make controlled experiments varying one parameter at a time.  
> The question here is how you chose the
>> work that can help us understand the problem better. But with all  
>> due respect, I simply cannot agree that this is a valid bittorrent  
>> model. Hence, I don't see why those results would give us knowledge  
>> about how the deployed ALTO system would perform in the real-world.
>
> All depends on what you mean by knowledge. Don't attribute to our  
> study a larger scope than what we described.
> Our study simply says that if you increase the locality up to very  
> high values
> Forget about absolute values, they are only there to compare  
> different experiments in the context of our study.
> If you claim that we haven't shown that it makes sense to consider  
> high locality values, then I have to disagree.
>
> Regards,
> Arnaud.

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 05 Dec 2008 11:55:59 +0100

This is actually a very interesting discussion, probably a perfect fit
for the IRTF P2P Research Group whose new charter (still under
refinement, AFAIK) will likely includes any research topics related to
P2P traffic localization.

I'd suggest to whoever is interested in this discussion to take a look
at the P2PRG page (http://irtf.org/charter?gtype=rg&group=p2prg) and
feel free to keep the conversation alive on the p2prg mailing list (now
Cc'ed).

Enrico

---

From: stefano previdi <[email-masked]>
Date: Tue, 09 Dec 2008 11:55:01 +0100

> From: Enrico Marocco <[email-masked]>
> 

indeed. We (Volker and myself with help from Aaron) are re-chartering the
p2prg in order to include any topic/issue related to p2p networking.

Anyone willing to contribute, please have a look at the wiki page:
http://trac.tools.ietf.org/group/irtf/trac/wiki/PeerToPeerResearchGroup
We tried to setup an "initial" list of topics we'd like to see addressed.

Any question, suggestions, comment or flame, feel free to send it to Volker
([email-masked]), myself or the list ([email-masked]).

Thanks.

s.