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

From: Laird Popkin <[email-masked]>
Date: Sat, 2 Aug 2008 16:57:00 -0400 (EDT)

Ignoring the sarcasm, I agree with much of what you've written, with the caveat that the answers that the oracle provides need to be relative to some point. For example, the answer to the question "which IP ranges are local" is by definition different for each locality that the ISP cares about. Also, for many p2p architectures this service needs to be accessible by a third party (e.g. a Tracker) asking on behalf of a client, and should be applicable to any p2p network (or other application) so the mechanism described would need to be generalized somewhat. 

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

----- Original Message ----- 
From: "Stanislav Shalunov" <[email-masked]> 
To: [email-masked] 
Sent: Saturday, August 2, 2008 4:32:11 PM (GMT-0500) America/New_York 
Subject: [p2pi] ALTO service privacy, performance, and architecture 

Much time has been spent discussing the operation of a sorting oracle or oracles answering questions like "What is the load on this link?", "Where did I put my glasses?", "How can I make $100M dollars this year?", "What is the link capacity between 1.2.3.4 and 1.2.3.5?", "If I were to send a packet to 1.2.3.4 after my next scheduling slice in the OS ends and I start to feel pretty, what would be the delay?".  A sorting oracle is a useful concept to consider when thinking about the system as a whole.  The oracle that answers questions it can't possibly answer is not a useful concept.  

A literal sorting oracle operated by the ISP will, however, *not* be queried by P2P apps and is, therefore, not relevant. 

Passing just a few IP numbers to such an oracle is not enough because it won't solve the localization problem: chances are none of the few are nearby. 

Passing the entire swarm or nearly the entire swarm to the oracle is not something that we would do in BitTorrent.  I expect other P2P apps with users will also not consider this privacy horror seriously. 

The sorting needs to happen inside the client. 

P2P apps already can easily have a lot of information about the network topology.  For example, it is entirely practical to download the entire Internet routing table to every client and keep it current.  The routing table, is of course, publicly available at a looking glass near you.  What P2P apps don't know about the topology is what the ISP would actually prefer. 

The sort of things that it would be useful to know are: 

* Does the ISP prefer local traffic? 

* Which IP ranges are local? 

* Are there any IP ranges best avoided?  (Mobile or DSL when fiber is available, for example.) 

Here is an example of a solution that would answer this sort of questions. 

1. The client discovers an URL using a mechanism similar to BEP 22.  Say the URL is http://nms.example.net/ip-routing-policy 

2. The client checks how long ago it has downloaded this URL.  If more than a month ago, downloads again.  The URL is a file containing things like: 

IP4:1.2.3/24 prefer 
IP4:1.2.4/24 avoid 
ASN:16 prefer 
ASN:18 prefer 

Such a solution would be very useful for P2P apps.  ISPs will be able to decide how much information they want to reveal about their own network topology and business arrangements.  The amount of information revealed is the same as through a literal sorting oracle if I'm allowed to ask an unlimited number of sorting questions.  Every concerned party will thus have an incentive to use this solution.  Solution is also easy to deploy: for discovery, the ISP will need to add one line to a forward DNS zone file; for the actual service, it'll need to use a simple script in daily cron to post-process "show ip bgp" output or equivalent. 

The discovery mechanism would be easy to generalize and use for other kinds of discovery. 

The ALTO information service would be useful for anything that can choose traffic sources/destinations: P2P, CDN, mirror selection, etc. 

-- 
Stanislav Shalunov 

Hacking Startups

_______________________________________________ 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: Laird Popkin <[email-masked]>
Date: Sat, 2 Aug 2008 17:33:59 -0400 (EDT)

Keep in mind that there's no real difference between "getting a file from an URL" and "getting a response from a web service", since any parameters that would be in the request could also be in the URL, and the response "file" could be dynamically generated if desired. So the only difference is in more subtle tradeoffs, such as personal preferences and fairly small differences in efficiency (e.g. constructing an URL is less work than constructing a SOAP request).

The format of the returned data is actually more of an issue, since the data volume is larger, making issues of efficiency more important. We're using XML right now, which is actually fairly space efficient (LZW does very well with XML) but an XML parser has much more overhead than a more limited message handler probably would, so it could make sense to move to some other data format, so long as it's extensible, versioned, etc.

----- Original Message -----
From: "Y. Richard Yang" <[email-masked]>
To: "Stanislav Shalunov" <[email-masked]>
Cc: [email-masked]
Sent: Saturday, August 2, 2008 5:18:20 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO service privacy, performance, and architecture

Hi Stansilav,

In short, I like your points.

The P4P team, including those here at Yale and Laird, had thought about 
the type of interface for a while. There were many discussions on the 
type of interface, in particular, a sorting interface or the P4P 
interface or some other type of interface (e.g., your proposal).  We 
argue that the sorting interface, although simple and can be considered 
as a special case of the p4p distance (vcost) interface, we feel that it 
is limited and can have many issues. The virtual cost interface used in 
the current P4P field test actually is quite similar to your proposal, 
with three differences:

- Like Laird said in the previous email, we allowing the addition of 
sources, instead of only destinations, for specifying ISP preference.

- Instead of a binary value (avoid/prefer), we allow a range of 
numerical values.

- we query the ISP servers, instead of URL/HTML web pages. Directly 
using a URL is quite interesting. We will need be able to update the web 
page, access control, etc.

Richard

Stanislav Shalunov wrote:
> Much time has been spent discussing the operation of a sorting oracle 
> or oracles answering questions like "What is the load on this link?", 
> "Where did I put my glasses?", "How can I make $100M dollars this 
> year?", "What is the link capacity between 1.2.3.4 and 1.2.3.5?", "If 
> I were to send a packet to 1.2.3.4 after my next scheduling slice in 
> the OS ends and I start to feel pretty, what would be the delay?". 
>  A sorting oracle is a useful concept to consider when thinking about 
> the system as a whole.  The oracle that answers questions it can't 
> possibly answer is not a useful concept. 
>
> A literal sorting oracle operated by the ISP will, however, *not* be 
> queried by P2P apps and is, therefore, not relevant.
>
> Passing just a few IP numbers to such an oracle is not enough because 
> it won't solve the localization problem: chances are none of the few 
> are nearby.
>
> Passing the entire swarm or nearly the entire swarm to the oracle is 
> not something that we would do in BitTorrent.  I expect other P2P apps 
> with users will also not consider this privacy horror seriously.
>
> P2P apps already can easily have a lot of information about the 
> network topology.  For example, it is entirely practical to download 
> the entire Internet routing table to every client and keep it current. 
>  The routing table, is of course, publicly available at a looking 
> glass near you.  What P2P apps don't know about the topology is what 
> the ISP would actually prefer.
>
> 1. The client discovers an URL using a mechanism similar to BEP 22. 
>  Say the URL is http://nms.example.net/ip-routing-policy
>
> 2. The client checks how long ago it has downloaded this URL.  If more 
> than a month ago, downloads again.  The URL is a file containing 
> things like:
>
> IP4:1.2.3/24 prefer
> IP4:1.2.4/24 avoid
> ASN:16 prefer
> ASN:18 prefer
>
> Such a solution would be very useful for P2P apps.  ISPs will be able 
> to decide how much information they want to reveal about their own 
> network topology and business arrangements.  The amount of information 
> revealed is the same as through a literal sorting oracle if I'm 
> allowed to ask an unlimited number of sorting questions.  Every 
> concerned party will thus have an incentive to use this solution. 
>  Solution is also easy to deploy: for discovery, the ISP will need to 
> add one line to a forward DNS zone file; for the actual service, it'll 
> need to use a simple script in daily cron to post-process "show ip 
> bgp" output or equivalent.
>
> The ALTO information service would be useful for anything that can 
> choose traffic sources/destinations: P2P, CDN, mirror selection, etc.
>
> --
> Stanislav Shalunov <http://shlang.com/>
>
> Hacking Startups <http://feeds.feedburner.com/%7Er/shlang/%7E6/1>
>
> ------------------------------------------------------------------------
>

---

From: Laird Popkin <[email-masked]>
Date: Sat, 2 Aug 2008 22:27:31 -0400 (EDT)

I'm a little confused about closed/open distinction, and the statement that "the whole point is to stay within the private tracker's given peers". All swarm delivery networks that I'm familiar with perform data exchanges only between peers that have the same content, which are coordinated by the same Tracker (or DHT, etc.), so all swarms contain only "the private tracker's given peers". Neither P4P nor ALTO change this. Or am I missing something?

Localizing traffic only has an impact if the swarm is large enough that there are likely to be "nearby peers", and if the time that it would take a peer to explore the entire swarm is worth saving. If a swarm only has ten peers globally, there's no benefit in attempting to localize traffic, because the p2p network will connect to and use all ten peers quite rapidly no matter what P4P/ALTO says. But if there is a large swarm and there are even a few peers near a new downloader (e.g. same or nearby ISP), there's good opportunity to optimize transit. For example, we found that if a FTTH user finds even one FTTH peer, their download speeds were much, much better than if they downloaded only from random users on the internet, so the value of optimizing connections between even a few FTTH users was quite high.

----- Original Message -----
From: "Richard Alimi" <[email-masked]>
To: "Reinaldo Penno" <[email-masked]>
Cc: [email-masked]
Sent: Saturday, August 2, 2008 9:11:48 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO service privacy, performance, and architecture

> 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"?

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

> 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 :)

Getting adoption in major public P2P clients/trackers is certainly important 
in order for this to make a large difference for ISP networks.

-- 
Richard Alimi
Department of Computer Science
Yale University

---

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 4 Aug 2008 10:55:38 -0400

Maybe we ought to distinguish between opt-in transparency (ie the user can know what is going on, and can opt-in or opt-out as desired) and usage transparency (ie once the user preference is selected, little intervention by the user is needed). I suspect both 'transparency types' are needed.

Users and applications won't adopt any ISP preference selections unless they see the benefits to them. I think this has to be a win-win (for the user/app and for the ISP) if Alto is going to succeed.

(I am assuming ISP-supplied preferences of course.)

-- Rich

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Reinaldo Penno <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Mon Aug 04 09:59:41 2008
Subject: Re: [p2pi] ALTO service privacy, performance, and architecture

On Aug 3, 2008, at 2:46 AM, Reinaldo Penno wrote:

> Laird,
>
>
> 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.
>
> I would say they care a lot. You statement that you "don't think p2p  
> users
> will know" does not seem to reflect the transparency we need. Doing  
> anything
> under the covers already proved disastrous.

I would tend to agree, especially for the power users. Remember the  
extensive on-line discussion
of TCP resets.

Regards
Marshall

>
>
> Once bitten, twice shy. I would be surprised if users/EFF/consumers  
> groups
> do not scrutinize what is happening with, within the ALTO protocol  
> and how
> their information will be used. You have to see it from the users  
> point of
> view, the people that complained to the FCC, had connections
> dropped/policed/whatever, go to messages board in droves to  
> complain, etc.
>
> Thanks,
>
> Reinaldo
>
>
>
> 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.
>>
>> 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.
>>
>> "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?
>>
>> 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
>> 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
>>>
>>> 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
>>> Hi,
>>> Thanks for your answers. Comments inline.
>>>
>>> On 8/2/08 6:11 PM, "Richard Alimi" <[email-masked]> wrote:
>>>
>>>> Let me make one clarification to your statement above.  The  
>>>> itracker in P4P
>>>> is
>>> 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.
>>>
>>>>
>>> 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.
>>>
>>>>
>>> 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.
>>>
>>>>
>>> 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
>>>
>>>