Subject: Re: [p2pi] ALTO service privacy, performance, and architecture

From: Laird Popkin <[email-masked]>
Date: Sun, 3 Aug 2008 07:15:28 -0400 (EDT)

Regarding the question of whether users know about ALTO, I think that you're reading too much into ALTO. P2P networks already control who users connect to and exchange data with, transparently to users. ALTO doesn't change anything other than that the ISPs are providing some assistance.

Regarding public tracker's incentives to implement this, I am not sure why you assume that they don't want their users to have fast download speeds. Users care a lot about download speeds, and would be happy to switch to whichever tracker gave them the best performance. And the people that run trackers care a lot about whether people use them. This is probably why, when I've talked to people that run trackers, they'd be very happy to implement a performance optimization that made their downloads faster. Their concerns are more regarding complexity of implementation, and in working with the ISPs to get the guidance.

Regarding the statement that "a client can easily get access to a full BGP routing table and perform some optimizations itself", while theoretically a p2p client could retrieve and use full BGP tables, but in practice BGP routing tables are quite large and complex, so I'm not sure that I would call doing this 'easy' to the point where millions of desktop applications should be doing it. It's far more efficient for this kind of work to be done in a centralized server that the clients can query for guidance, IMO.

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

----- Original Message -----
From: "Reinaldo Penno" <[email-masked]>
To: "Laird Popkin" <[email-masked]>
Cc: [email-masked], "Richard Alimi" <[email-masked]>
Sent: Sunday, August 3, 2008 2:03:31 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO service privacy, performance, and architecture

On 8/2/08 9:09 PM, "Laird Popkin" <[email-masked]> wrote:

> I don't think that p2p users will know or care about ALTO, any more than they
> know or care about BGP, or HTTP proxies - things just work. ALTO will need to
> be known about and implemented either by the p2p trackers or clients. At most
> some applications might provide an ALTO check box as a preference setting,
> just as they might allow for manual proxy configuration.

At most or always? If you make it mandatory you are deciding on behalf of
the users who he/she should connect and you are dealing in the net
neutrality realm. I'm not sure MSO and Telcos want to go through FCC battles
again.

> 
> Answering the question "And the motivation for pirate trackers would be? ...
> Improve performance seems slim.", I believe that there are two benefits, one
> direct and one indirect.
> 
> The direct benefit is that localizing data transfers improves download
> performance for users significantly on average, which makes users happier.
> While theoretically it shouldn't matter whether data is pulled from nearby
> sources or far, in practice localizing data sources appears to improve
> performance quite a bit. I can only guess what the cause of the improved
> performance is (perhaps shorter RTT's improve TCP throughput, perhaps avoiding
> congested internet gateways). In any case, we're seeing real world download
> speeds double and triple for users on fast broadband connections (nothing will
> speed up a slow broadband connection...).
> 
> The indirect benefit is that by reducing the transit costs created by p2p
> traffic, it reduces the incentives for ISPs to degrade p2p traffic.

I was talking about what were the incentives for public trackers to perform
optimizations. Your arguments seem to be ISP centric. Public trackers do not
care or are very happy with the current download speeds of their users.
Statistics from these trackers show more bandwidth consumed in a month than
all itunes music sold to date.

> 
> "Clients can potentially improve their own performance by choosing closer
> peers based on IP addresses." How would they know which IP addresses are
> closer? ALTO?

As Stas suggested, a client can easily get access to a full BGP routing
table and perform some optimizations itself. Is this ALTO?

> 
> - Laird Popkin, CTO, Pando Networks
>   mobile: 646/465-0570
> 
> ----- Original Message -----
> From: "Reinaldo Penno" <[email-masked]>
> To: "Laird Popkin" <[email-masked]>
> Cc: [email-masked], "Richard Alimi" <[email-masked]>
> Sent: Saturday, August 2, 2008 10:58:44 PM (GMT-0500) America/New_York
> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture
> 
> 
> 
> 
> On 8/2/08 7:35 PM, "Laird Popkin" <[email-masked]> wrote:
> 
>> The P4P tests that were performed so far were performed with legal content so
>> that we could focus on technical issues (e.g. implementing and running the
>> tests) and not get caught in potentially lengthy policy discussions that
>> (IMO)
>> are only worth having once the technology demonstrates its value. The test
>> results have been very good, so I suspect that the policy discussions will
>> start taking place. There's no technical issue limiting who uses P4P (and, I
>> hope, ALTO). Given this, I believe that each ISP can decide its own policies
>> regarding who it wants to share what information with.
> 
> Understood.
> 
>> 
>> Keep in mind that ALTO servers can be run by entities other than ISPs. So if
>> ISPs don't want to work with pirate trackers, the pirate trackers might join
>> together to set up an ALTO server populated using whatever network
>> information
>> they can collect or determine (e.g. ASN adjacency maps) to improve
>> performance
>> for their users.
> 
> And the motivation for pirate trackers would be? There is no business
> relationship between P2P clients and their public trackers. Improve
> performance seems slim. Clients can potentially improve their own
> performance by choosing closer peers based on IP addresses.
> 
>> 
>> Finally, ALTO servers should be accessible by either clients or servers, so
>> it
>> may be the case that even if ISPs don't want to work with pirate trackers,
>> they might approve working with user p2p clients, which would achieve a
>> similar result.
> 
> The latter requires a leap of faith. That's where I think we have different
> opinions. I think we need to make sure P2P users are on-board. BTW, by P2P
> clients you mean the P2P software or P2P users?
> 
> Thanks,
> 
> Reinaldo
>> 
>> - Laird Popkin, CTO, Pando Networks
>>   mobile: 646/465-0570
>> 
>> ----- Original Message -----
>> From: "Reinaldo Penno" <[email-masked]>
>> To: "Richard Alimi" <[email-masked]>
>> Cc: [email-masked]
>> Sent: Saturday, August 2, 2008 10:10:11 PM (GMT-0500) America/New_York
>> Subject: Re: [p2pi] ALTO service privacy, performance, and architecture
>> 
>> Hi,
>> 
>> Thanks for your answers. Comments inline.
>> 
>> On 8/2/08 6:11 PM, "Richard Alimi" <[email-masked]> wrote:
>> 
>>>> I just want to remind that we are here because of file-sharing and not
>>>> really closed P2P networks where itrackers, apptrackers and others
>>>> cooperate nicely. This is the easy case and today does not cause problems
>>>> to ISPs. And maybe never will.
>>> 
>>> Let me make one clarification to your statement above.  The itracker in P4P
>>> is
>>> not application specific, and thus is not part of any closed system.  It can
>>> be queried by many P2P applications, and does not keep any swarm state.  The
>>> field tests have been done with Pando, but nothing restricts it from being
>>> used for "public" P2P networks.
>>> 
>>> Or did I misinterpret your meaning of "closed"?
>> 
>> Closed as in the sense that it assumes cooperation from the AppTracker.
>> Otherwise how can it not keep any swarm state? This is is based on the
>> functionality from your paper.
>> 
>> Anyway, the two statements seem contradictory. The corollary is that the
>> content that such clients access are those of the P2P CDN and not pirated
>> content. The P4P trials that I have heard/read are based on legal content.
>> Please correct me if I'm wrong.
>> 
>>> 
>>>> So, when you say "tracker-less" systems you mean a P2P network without a
>>>> tracker (Gnutella) or a P2P network where the tracker is something like
>>>> thepiratebay? The two 'systems' (as you put it) are quite different.
>>> 
>>> By "tracker-less," I was referring to a P2P network without a tracker.  We
>>> consider thepiratebay a tracker-based system.
>>> 
>>>> In the case where there is a tracker on the Internet that does not
>>>> cooperate (which is 99.99% of P2P traffic today) I'm not sure how ALTO
>>>> would work without the ISP tracker pushing information to the clients
>>>> (since the clients might not send info to the tracker).
>>> 
>>> I agree that to cover the majority of the P2P traffic, it may be mostly be
>>> client-dependent in the beginning.
>>> 
>>> The idea, however, is that as time goes on P2P developers and ISPs will each
>>> realize the benefits (better performance for P2P apps, and achieve
>>> particular
>>> network goals for ISPs) and begin support.  Integration should be simple
>>> enough that P2P developers understand and use it.
>> 
>> It is not P2P developers that need to be convinced. It is the users, the
>> human factor. 
>> 
>> And if ALTO does not "get it" that it is not just about having a
>> client-server protocol, I'm not sure of the benefits. Yeah, Pando or Joost
>> users can be convinced of using it, but how about the other users that are
>> responsible for 99.9% of traffic? And if they cannot be convinced, can ALTO
>> still do some form of optimization? This goes back to security and privacy.
>> 
>>> 
>>>> For private trackers (which have the really hardcore users) it is not clear
>>>> how ALTO can influence their behavior since the whole point is to stay
>>>> within the private tracker's given peers. If we cannot tackle these two
>>>> scenarios, ISPs continue to suffer.
>>> 
>>> Interesting point. If there are limited peers in a swarm, then there are
>>> limited opportunities for optimization (both for the P2P and ISP side). Is
>>> this a fundamental limit, though? Aside, of course, from "telling" them that
>>> their swarms should be larger :)
>> 
>> Well, peers driven by private trackers are the elite. They do not really
>> need a big swarm since these are folks that have their computers on 24x7 and
>> have Seedboxes. Most of the time they have co-location boxes and/or pay
>> enterprise fees to have tons of bandwidth.
>> 
>>> 
>>> Getting adoption in major public P2P clients/trackers is certainly important
>>> in order for this to make a large difference for ISP networks.
>> 
>> I believe, as I said before, that we need to convince users. The only way to
>> convince such users is if we have a tight (very tight) security, privacy
>> model. Otherwise the ALTO protocol might not see use in the wild.
>> 
>> As far as convincing public trackers also means convincing the ISP to have a
>> relationship with such trackers as thepiratebay. Does Comcast or BT want to
>> have such relationship? I have no idea. I guess my point is that the
>> business/realities of P2P networks should drive the requirements so we can
>> work with (or around them).
>> 
>> Thanks,
>> 
>> Reinaldo
>> 
>> 
>> _______________________________________________
>> p2pi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2pi
> 
> 

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sun, 3 Aug 2008 11:11:02 -0400

-----Original Message-----
From: Laird Popkin [mailto:[email-masked]]
Sent: Sun 8/3/2008 4:15 AM
To: Reinaldo Penno
Cc: [email-masked]; Richard Alimi
Subject: Re: [p2pi] ALTO service privacy, performance, and architecture

[reinaldo]

yes, peer selection is random, and this randomness is a integral part of the algorithm and some argue one of its strengths. What we are saying is "instead of choosing peers randomly, give preference to these X instead". This changes the algorithm considerably.

[reinaldo]

I believe trackers want peers to have better download speeds, what I said is that today it already works well. If you talked to public trackers like thepiratebay, mininova and others and they are interested in exchanging info with ISPs that is interesting information.  

[reinaldo]

Yes and no. Both approaches have pros and cons. 

A centralized server is a single point of failure, needs to interface with the routers on the network to acquire such info since it is not part of the routing mesh. And if the client needs to ask for guidance it needs to send a list of IP/Prefixes/other to this centralized server every time it gets to know a new set of peers. 

If the policies are pushed (which can be done in a decentralized way), the client can apply the policies against the list of candidate peers.  We can even use multicast to push such policies if the network supports it.  Since the policies are network based (independent of torrrent), there is no need for the client to keep asking for policies every time it gets to know a new set of peers.  That of course does not preclude a client from contacting its closest ALTO Service/Server (not a centralized one) and ask for guidance.

---

From: Laird Popkin <[email-masked]>
Date: Sun, 3 Aug 2008 11:49:54 -0400 (EDT)

Comments below:

----- Original Message -----
From: "Reinaldo Penno" <[email-masked]>
To: "Laird Popkin" <[email-masked]>
Cc: [email-masked], "Richard Alimi" <[email-masked]>
Sent: Sunday, August 3, 2008 11:11:02 AM (GMT-0500) America/New_York
Subject: RE: [p2pi] ALTO service privacy, performance, and architecture

-----Original Message-----
From: Laird Popkin [mailto:[email-masked]]
Sent: Sun 8/3/2008 4:15 AM
To: Reinaldo Penno
Cc: [email-masked]; Richard Alimi
Subject: Re: [p2pi] ALTO service privacy, performance, and architecture

[reinaldo]

[laird] Not really. All P2P networks make decisions about which peers to exchange data between in order to optimize p2p performance. ALTO would be an additional input into that decision.

[reinaldo]

[laird] While it's true that p2p networks already work well, it also appears to be true that there's significant room for improvement. Specifically, in field testing localizing traffic significantly improves performance when compared to pure random peer connections. As I wrote earlier, I can't prove why this occurs, but I can certainly document that downloads that localize transfers are on average significantly faster than downloads that don't do so. It may be caused by TCP operating better with shorter RTT's. It might be avoiding ISP's saturated internal or external links, or even general internet traffic. But it seems clear that localizing traffic benefits performance on average.

Given this, tracker sites appear to have a clear incentive to improve performance by implementing traffic localization.

[reinaldo]

[laird] I certainly agree that there are both centralized and decentralized p2p networks. My point was that even if theoretically every p2p client could retrieve and process the ISP's full BGP tables, practically speaking that doesn't preclude the value of a central server that does that work and makes the results available in a more compact, easily processable, standardized format.

---

From: Reinaldo Penno <[email-masked]>
Date: Sun, 03 Aug 2008 10:52:16 -0700

Do not take BGP routing table as a proposed solution. It was just an
example. Maybe not a good one for the sake of this discussion.

The point I was trying to get across is that ISPs can push policies (the
result of the decentralized computation) to clients and they can use these
policies as they see fit, using whatever algorithm they want.

This way clients do not need to send info about peers to the ISP.

On 8/3/08 8:49 AM, "Laird Popkin" <[email-masked]> wrote:

> Regarding the question of whether users know about ALTO, I think that you're
> reading too much into ALTO. P2P networks already control who users connect to
> and exchange data with, transparently to users. ALTO doesn't change anything
> other than that the ISPs are providing some assistance.
> 
> [reinaldo]
> 
> yes, peer selection is random, and this randomness is a integral part of the
> algorithm and some argue one of its strengths. What we are saying is "instead
> of choosing peers randomly, give preference to these X instead". This changes
> the algorithm considerably.
> 
> [laird] Not really. All P2P networks make decisions about which peers to
> exchange data between in order to optimize p2p performance. ALTO would be an
> additional input into that decision.
> 
> Regarding public tracker's incentives to implement this, I am not sure why you
> assume that they don't want their users to have fast download speeds. Users
> care a lot about download speeds, and would be happy to switch to whichever
> tracker gave them the best performance. And the people that run trackers care
> a lot about whether people use them. This is probably why, when I've talked to
> people that run trackers, they'd be very happy to implement a performance
> optimization that made their downloads faster. Their concerns are more
> regarding complexity of implementation, and in working with the ISPs to get
> the guidance.
> 
> [reinaldo]
> 
> I believe trackers want peers to have better download speeds, what I said is
> that today it already works well. If you talked to public trackers like
> thepiratebay, mininova and others and they are interested in exchanging info
> with ISPs that is interesting information.
> 
> [laird] While it's true that p2p networks already work well, it also appears
> to be true that there's significant room for improvement. Specifically, in
> field testing localizing traffic significantly improves performance when
> compared to pure random peer connections. As I wrote earlier, I can't prove
> why this occurs, but I can certainly document that downloads that localize
> transfers are on average significantly faster than downloads that don't do so.
> It may be caused by TCP operating better with shorter RTT's. It might be
> avoiding ISP's saturated internal or external links, or even general internet
> traffic. But it seems clear that localizing traffic benefits performance on
> average.
> 
> Given this, tracker sites appear to have a clear incentive to improve
> performance by implementing traffic localization.
> 
> Regarding the statement that "a client can easily get access to a full BGP
> routing table and perform some optimizations itself", while theoretically a
> p2p client could retrieve and use full BGP tables, but in practice BGP routing
> tables are quite large and complex, so I'm not sure that I would call doing
> this 'easy' to the point where millions of desktop applications should be
> doing it. It's far more efficient for this kind of work to be done in a
> centralized server that the clients can query for guidance, IMO.
> 
> [reinaldo]
> 
> A centralized server is a single point of failure, needs to interface with the
> routers on the network to acquire such info since it is not part of the
> routing mesh. And if the client needs to ask for guidance it needs to send a
> list of IP/Prefixes/other to this centralized server every time it gets to
> know a new set of peers.
> 
> If the policies are pushed (which can be done in a decentralized way), the
> client can apply the policies against the list of candidate peers.  We can
> even use multicast to push such policies if the network supports it.  Since
> the policies are network based (independent of torrrent), there is no need for
> the client to keep asking for policies every time it gets to know a new set of
> peers.  That of course does not preclude a client from contacting its closest
> ALTO Service/Server (not a centralized one) and ask for guidance.
> 
> [laird] I certainly agree that there are both centralized and decentralized
> p2p networks. My point was that even if theoretically every p2p client could
> retrieve and process the ISP's full BGP tables, practically speaking that
> doesn't preclude the value of a central server that does that work and makes
> the results available in a more compact, easily processable, standardized
> format.
>

---

From: "Robb Topolski" <[email-masked]>
Date: Sun, 3 Aug 2008 11:50:12 -0700

>
> yes, peer selection is random, and this randomness is a integral part of
> the algorithm and some argue one of its strengths. What we are saying is
> "instead of choosing peers randomly, give preference to these X instead".
> This changes the algorithm considerably
>

I know that you understand this Laird, but not everyone might understand it:

Peer selection is random when peers are being added to a list to be
delivered to a client.  However, the peers in that client list that will
eventually pair and exchange data for extended periods of time is not random
-- they are the 2-3** best (fastest) pairs in that list.  So far, I haven't
seen anything in the P4P suggestions that threatens this important,
efficient, and congestion-avoiding feature, *and it's essential that P4P
doesn't threaten it.*

As closest peers are likely to be fastest, all other things considered, the
hope for P4P peer localizing is that it can short-cut the time it takes for
great peer pairings to find one another and pair up for extended
transferring. This savings is realized because it might take the "random"
method one to several tracker queries to deliver the same best peers that
P4P could deliver in the first query.  (Of course, please correct me if I'm
misunderstanding something.)

(**typical, but this is configurable and defaults are higher depending on
the users' uplink speeds at install time.)
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Laird Popkin <[email-masked]>
Date: Sun, 3 Aug 2008 15:22:27 -0400 (EDT)

Great explanation, Robb. 

To elaborate on the topic of randomness a bit, randomness in peer connections is indeed extremely important in order for the peer mesh to be resilient - if peers always get the same set of "best" peers to connect to, over and over again, that would be extremely harmful to the p2p mesh, because the p2p mesh would be fragile (i.e. too few connections), and swarms would tend to be segmented into well connected peers within each ISP, isolated from each other. To balance between locality and randomness, we did a couple of things: 

- We implemented a 'weighted random' model in the P4P testing, where the probability of connecting to peers in specific network locations is determined by the ISP's iTracker (AKA ALTO tracker), but the p2p network picks random peers based on that probability for each response list sent, so the specific peer list varies in every response. 
- We always return at least 20% pure random peers (i.e. from the global list) in order to make sure that the swarm doesn't get segmented between ISPs. 

The result of this is that peers tend to connect to nearby peers first, establishing (hopefully) fast, cheap connections. Then over time the p2p mesh fills in, so the peer has a chance to exchange data with the further peers. If the local peers are indeed the fastest, the further connections won't be used much, as we (like many p2p networks) use the fastest available peers, so localization provides a good speed boost. If the remote peers are faster than the local peers, we find that out and use them instead of the local peers fairly quickly, so localizing doesn't hurt performance for too long. 

----- Original Message ----- 
From: "Robb Topolski" <[email-masked]> 
To: "Reinaldo Penno" <[email-masked]> 
Cc: "Laird Popkin" <[email-masked]>, [email-masked] 
Sent: Sunday, August 3, 2008 2:50:12 PM (GMT-0500) America/New_York 
Subject: Re: [p2pi] ALTO service privacy, performance, and architecture 

yes, peer selection is random, and this randomness is a integral part of the algorithm and some argue one of its strengths. What we are saying is "instead of choosing peers randomly, give preference to these X instead". This changes the algorithm considerably 

Peer selection is random when peers are being added to a list to be delivered to a client.  However, the peers in that client list that will eventually pair and exchange data for extended periods of time is not random -- they are the 2-3** best (fastest) pairs in that list.  So far, I haven't seen anything in the P4P suggestions that threatens this important, efficient, and congestion-avoiding feature, and it's essential that P4P doesn't threaten it.   

As closest peers are likely to be fastest, all other things considered, the hope for P4P peer localizing is that it can short-cut the time it takes for great peer pairings to find one another and pair up for extended transferring. This savings is realized because it might take the "random" method one to several tracker queries to deliver the same best peers that P4P could deliver in the first query.  (Of course, please correct me if I'm misunderstanding something.) 

(**typical, but this is configurable and defaults are higher depending on the users' uplink speeds at install time.) 
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Laird Popkin <[email-masked]>
Date: Sun, 3 Aug 2008 15:23:47 -0400 (EDT)

In that case we're in violent agreement. :-)