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

From: Stanislav Shalunov <[email-masked]>
Date: Sat, 2 Aug 2008 14:37:56 -0700

There is a resolution of "local" that's very special and relevant for the ISP.  This resolution is also relevant for users in counties where per bit end-user charges are conventional.

"Local" = the ISP pays external parties nothing per bit.

The ISP will likely choose not to reveal every IP range with this property, but revealing some would already be useful.

Finer resolusions than this are less useful, because you need roughly 20 local peers for localization on DSL or cable and getting this many out of the thousands in the biggest swarms that are in this largest local zone is already challenging.

Some further localization could be made possible with source dependence and weights, but that's probably overkill.

Third-party queries can go either way.  The tracker could learn from peers if such queries are not supported.  In the architecture I describe, starting with an IP address other than your own will result an answer other than local.  The ISP can control access to the URL by source IP.

Does this make sense?

-- Stas

-----Original Message-----
From: "Laird Popkin" <[email-masked]>
To: "Stanislav Shalunov" <[email-masked]>
Cc: [email-masked]
Sent: 8/2/08 1:57 PM
Subject: Re: [p2pi] ALTO service privacy, performance, and architecture

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 .  

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

---

From: "Y. R. Yang" <[email-masked]>
Date: Sat, 2 Aug 2008 18:00:19 -0400 (EDT)

On Sat, 2 Aug 2008, 2:37pm -0700, Stanislav Shalunov wrote:

> There is a resolution of "local" that's very special and relevant for 
> the ISP.  This resolution is also relevant for users in counties where 
> per bit end-user charges are conventional.

> The ISP will likely choose not to reveal every IP range with this 
> property, but revealing some would already be useful.

> Finer resolutions than this are less useful, because you need roughly 20 
> local peers for localization on DSL or cable and getting this many out 
> of the thousands in the biggest swarms that are in this largest local 
> zone is already challenging.

I take your local (i.e., not paying external parties) means within the 
same ISP. From our running test, we do often can see many local choices
and thus would like more information to make the choice.

Another reason for finer information is that you may not want to choose 
only local. The preference can be

<local 1> _is_better_than_ <external ASN 2> _is_better_than_ <local 2>

This showed up in our current experiment (configured by an ISP), and 
turned out to be able to help applications very well.

Do you think this will be too complicated?

Richard

> Some further localization could be made possible with source dependence 
> and weights, but that's probably overkill.

> Third-party queries can go either way.  The tracker could learn from 
> peers if such queries are not supported.  In the architecture I 
> describe, starting with an IP address other than your own will result an 
> answer other than local.  The ISP can control access to the URL by
> source IP.

---

From: Richard Alimi <[email-masked]>
Date: Sat, 2 Aug 2008 18:15:48 -0400

On Saturday 02 August 2008 17:37:56 Stanislav Shalunov wrote:
> There is a resolution of "local" that's very special and relevant for the
> ISP.  This resolution is also relevant for users in counties where per bit
> end-user charges are conventional.
>

Another possibility is for "locality" to not be a spatial/geographic concept. 
One idea that we have considered in P4P was to define PIDs for different 
congestion states. For example, one could define 3 PIDs: high-congestion, 
medium-congestion, and low-congestion. Then, (e.g., in a cable network) CMTSs 
can be periodically moved between PIDs based on their level of detected 
congestion.  Then, for example, peers in the PID for low-congestion state can 
more-preferentially peer with each other and costs would be defined between 
each congestion state.  Of course, the nature of congestion (e.g., 
upstream/downstream) may also need to be taken into account.

> Third-party queries can go either way.  The tracker could learn from peers
> if such queries are not supported.  In the architecture I describe,
> starting with an IP address other than your own will result an answer other
> than local.  The ISP can control access to the URL by source IP.

For tracker-based systems, how does this work?  The source IP address for such 
a query would be the tracker IP address, instead of the client's IP address 
(which should be the frame-of-reference for any recommendations). 

Or, are you envisioning that clients retrieve the recommendations and then 
merge them with whatever information the tracker sends them?  Or do clients 
then forward these recommendations to the tracker to utilize in its peer 
selection?

-- 
Richard Alimi
Department of Computer Science
Yale University

---

From: Stanislav Shalunov <[email-masked]>
Date: Sat, 2 Aug 2008 16:43:48 -0700

On Aug 2, 2008, at 3:00 PM, Y. R. Yang wrote:
> same ISP.

Mostly broader than that.  No-cost peering arrangements are common and  
often exposed to the users already, just not in a machine-readable form.

> From our running test, we do often can see many local choices

The choice between zero cost and zero cost is probably not something  
the ISP cares deeply about, thus it would have little incentive to  
provide more detailed resolution of information about its network.

As an aside, being able to use only same-AS peers is very uncommon in  
BitTorrent swarms that comprise most of P2P network use.

> Do you think this will be too complicated?

This should fit nicely into what I describe if we replace avoid/prefer  
with a numeric cost scale.  The ISP needs to have an incentive to  
provide the information for the scheme to be deployable.  The ISP has  
a strong incentive to tell the apps what's free for it.  The apps have  
a good incentive to use it in countries without per-bit end-user  
charges (like the US) and an extremely strong incentive to use it in  
countries with per-bit end-user charges (most of the rest of the  
world).  In the former case, the app/user incentive is not provoking  
blocking/throttling, while in the latter case the incentive is  
reducing the bill for the user.

--
Stanislav Shalunov

---

From: Stanislav Shalunov <[email-masked]>
Date: Sat, 2 Aug 2008 16:51:12 -0700

> upstream/downstream) may also need to be taken into account.

This is transport information.  I don't think that conveying it  
belongs anywhere outside of the transport area.  ALTO is outside the  
transport area.

> merge them with whatever information the tracker sends them?

That's the main deployment path if we are to help the ISPs with the  
real problem.  There are many more tracker codebases that matter than  
client codebases that matter.

> Or do clients

I think this is a reasonable option if operators find an interface  
that takes source IP as an input worrisome.

--
Stanislav Shalunov

---

From: Richard Alimi <[email-masked]>
Date: Sat, 2 Aug 2008 20:31:18 -0400

> > [ .. example snipped .. ]
>

You're right that the particular example was related to transport-layer 
information, but the idea of extending "locality" to be more than a 
spatial/geographic concept may not be.

> client codebases that matter.

That is a good point, and particularly relevant for tracker-less systems.  I 
agree that clients should be able to perform queries themselves, but shouldn't 
trackers be able to perform queries as well should they choose to support it?

Allowing this at trackers may provide more opportunities for optimization 
since they know more swarm state (or possibly state across multiple swarms 
being hosted at the same tracker).

> that takes source IP as an input worrisome.

Do you think it is reasonable task for a tracker to merge individual 
recommendations (format of course is to be determined) amongst each individual 
client?  That seems quite difficult unless they have a particularly uniform 
structure.

---

From: Stanislav Shalunov <[email-masked]>
Date: Sat, 2 Aug 2008 17:47:56 -0700

> spatial/geographic concept may not be.

Perhaps.  I believe we should start with useful examples we can come  
up with and only generalize in obvious directions.

By the way, "no-cost" (the only real useful example I can think of)  
isn't necessarily geographic.

> trackers be able to perform queries as well should they choose to  

That would be fine.

> being hosted at the same tracker).

Some trackers know more, some less.  Remember that some trackers are  
really simple.  Popular clients all know quite a lot about the swarm.

> client?  That seems quite difficult unless they have a particularly  

I expect a tracker would just use this merged information to influence  
the peers it gives out to a given peer.  Might somehow publish it, in  
principle, but that will probably make ISPs uncomfortable if they were  
uncomfortable about the information being available outside of their  
network to begin with.

--
Stanislav Shalunov

---

From: Richard Alimi <[email-masked]>
Date: Sat, 2 Aug 2008 21:22:35 -0400

> uncomfortable about the information being available outside of their

Yes, but my question was concerning the merging of such ISP recommendations, 
and how to turn this into peer recommendations for each joining peer. That 
appears to be the particularly challenging part.

One simple option of course is to use only that joining peer's set of 
recommendations (prefer AS1, I don't like AS2), look into the current set of 
peers in the swarm, and choose a set that matches those recommendations.  More 
interesting things could probably be done with the merged set of information 
though.