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

From: Stanislav Shalunov <[email-masked]>
Date: Sat, 2 Aug 2008 13:32:11 -0700

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

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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sat, 02 Aug 2008 17:18:20 -0400

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:
> 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 
> 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.
>
> Here is an example of a solution that would answer this sort of questions.
>
> Stanislav Shalunov <http://shlang.com/>
>
> Hacking Startups <http://feeds.feedburner.com/%7Er/shlang/%7E6/1>
>
> ------------------------------------------------------------------------
>

---

From: Richard Alimi <[email-masked]>
Date: Sat, 2 Aug 2008 17:39:39 -0400

> page, access control, etc.

To add to Richard's last point, we have been rethinking our P4P protocol spec 
in the past couple of weeks and have been moving to a REST-based approach 
which would provide this behavior and would integrate well with authentication 
and access control (HTTP basic/digest auth, SSL certs) and encryption (SSL), 
and should ease adoption by P2P application developers.

Since some queries may be particularly common and small and SSL/HTTP/TCP may 
become an overhead (as has been mentioned before here by Laird and others), we 
are allowing certain queries via UDP.

-- 
Richard Alimi
Department of Computer Science
Yale University
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 02 Aug 2008 15:10:52 -0700

Is the P4P protocol public domain? I'm saying this because every time
somebody suggests a different approach the answer is invariably

"P4P can do this" or "we in P4P were _just_ thinking about this".

Any protocol candidate to IETF standardization needs to be public documented
in a RFC or some public domain site.  We (as in the wide public) need to
understand in-depth how P4P works, so it can be peer reviewed, everybody can
have a opinion about it and not just drink from the cool-aid.

Thanks,

Reinaldo

---

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

Hi Reinaldo,

The design principles of P4P are specified in some detail in this 
SIGCOMM'08 paper: 
http://cs-www.cs.yale.edu/homes/yry/projects/p4p/p4p-sigcomm08.pdf

Of course, the paper can be only 12 pages :-) and many details are not 
there. Also, the protocols/system are evolving, with extremely valuable 
discussions like in this group. Yale is considering releasing much of the 
system from the Yale side (ISP P4P configuration language (two versions), 
the protocol APIs, application optimization engine for computing peering 
guidelines for file sharing). Of course we will need to get permissions 
from others since it gets a lot of inputs from others.

Note that we have no detailed writeup. Many things (configuration 
language, protocol, API, and algorithms) are in code. I think writing them 
down will be on the agenda for the next P4P working group meeting on 
August 5. Any help will be greatly appreciated.

Richard

On Sat, 2 Aug 2008, 3:10pm -0700, Reinaldo Penno wrote:

> Any protocol candidate to IETF standardization needs to be public 
> documented in a RFC or some public domain site.  We (as in the wide 
> public) need to understand in-depth how P4P works, so it can be peer 
> reviewed, everybody can have a opinion about it and not just drink from 
> the cool-aid.
> 
> Thanks,
> 
> Reinaldo
> 
> 
> 
>

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 02 Aug 2008 16:00:21 -0700

Thanks for the response Richard. I'm very familiar with your paper.

I appreciate the effort but if distill your comments the answer is "no, no
public domain at this point", correct? It would be good to get timelines for
the release of information.

I'm not a member (as many others) of P4P so I'm not sure how much help I can
provide. On the other hand access to your code would be a good start, is
there a link to that?

But the bottom line is that I feel it very difficult as a IETF participant
to have discussions around a proprietary protocol that we do not have
access. At this point the information other IETF participants have regarding
P4P are functionality claimed in some emails that cannot be reviewed or
verified. 

Thanks,

Reinaldo

---

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

> sources, instead of only destinations, for specifying ISP preference.

It's important for privacy reasons that the app should not have to  
tell the ISP about every IP address it might consider connecting to.   
WRT asking about sources other than yourself, I'm fine either way,  
because the tracker can get the information from the peers.

> - Instead of a binary value (avoid/prefer), we allow a range of  

I'm just using prefer/avoid as examples.  The actual format and  
semantics can be different.

> using a URL is quite interesting. We will need be able to update the  
> web page, access control, etc.

That's nearly the same.  I would definitely not make the format HTML.   
(Personally, I'd prefer a microformat, but XML, as heavy as it is,  
would be functionally close.)  It doesn't even need to be an HTTP URL,  
of course.

The sort of architecture I describe is one example of where your P4P  
trackers could get the information from.  Generic building blocks are  
good.

Thank you,

--
Stanislav Shalunov

---

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

> are allowing certain queries via UDP.

Not sure which queries these are.  I find it unlikely that large- 
volume queries would not have prohibitive privacy implications.  What  
else would one ask for a lot if it's not a bunch of possible  
destination IPs?

--
Stanislav Shalunov

---

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

> else would one ask for a lot if it's not a bunch of possible

The query in the P4P protocol that I'm referring to is for a client to obtain 
its PID (a la DHCP).  It locates its ISP's iTracker (e.g., via DNS SRV), 
queries for its PID, and then uses that (iTracker,PID) pair when either 
registering with an application tracker, or querying the iTracker itself 
(e.g., for tracker-less systems).  ISPs with many subscribers may need this to 
be UDP.

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 02 Aug 2008 17:24:53 -0700

Hi,

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.

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.

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

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.

Thanks,

Reinaldo

---

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

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

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

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

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 02 Aug 2008 19:10:11 -0700

Hi,

Thanks for your answers. Comments inline.

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

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

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

> 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

---

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

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.

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.

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.

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

Reinaldo

---

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

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

In the paper, you're right that the primal-dual decomposition and the 
supergradient tending towards the optimal network state depends on both code 
implemented in the iTracker and the application tracker.  However, as we've 
pointed out, this is not the only way the costs distributed by the tracker 
need to be used - it is just one example.  Other algorithms implemented at 
either side may not relate to a particular problem formulation, but 
nonetheless the ISP preferences can still be conveyed and followed.

> Please correct me if I'm wrong.

You are right - the trials have used legal content, but there is nothing in 
the system that prevents it being used by other trackers.

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

In the end, the users are not the ones using the provided information, it is 
the P2P software on their desktops/laptops.  As a P2P user, is there any more 
involvement I have beyond downloading an ALTO-enabled client or connecting to 
an ALTO-enabled tracker, and possibly changing a few configuration options to 
enable/disable ALTO or tune how my client uses the recommendations?

Yes, users may ask the P2P developer for support, but for word to spread 
amongst users they'll have to see their friends using ALTO-enabled P2P 
clients/trackers.

If integration is particularly hard, it seems that this adoption will be very 
difficult to bootstrap and eventually integrate into the large number of P2P 
client/tracker implementations out there.

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

See above - you're right that security/privacy is an important issue for the 
P2P users and is important for adoption.

> 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

Are you referring to a business relationship, or a "I won't prevent you from 
connecting to me" relationship?  I don't think any business relationship is 
required, but I can't comment on the second interpretation.

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 02 Aug 2008 19:58:44 -0700

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: Stanislav Shalunov <[email-masked]>
Date: Sat, 2 Aug 2008 20:09:42 -0700

> enable/disable ALTO or tune how my client uses the recommendations?

Most trackers will probably not support ALTO in any near future.

There are about three very popular clients that really matter.  I am  
familiar with how decisions work for the first of these clients, but I  
expect that any other popular client will have similar considerations,  
and will need to make similar changes to stay popular.

Whether clients will support ALTO mainly depends on whether

(1) downloads will go as fast
(2) no party, particularly not the ISP, will learn more about what's  
going on than it does today

I'm somewhat skeptical of possibility of great improvements in average  
download speeds.  Such possibility would imply that there are vast  
amount of upload capacity that sit unused in a regular unwashed  
swarm.  While there can be substantial local improvements to be made  
every now and then, the system clearly gives very high average uplink  
use fraction when comprised of decent clients.  Given how thin the  
uplink is, it's not too hard to use it all regardless of RTT,  
particularly with several active connections.

--
Stanislav Shalunov

---

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

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

> (2) no party, particularly not the ISP, will learn more about what's going on
> than it does today

Agree.
 
> download speeds.  Such possibility would imply that there are vast amount of
> upload capacity that sit unused in a regular unwashed swarm.  While there can
> be substantial local improvements to be made every now and then, the system
> clearly gives very high average uplink use fraction when comprised of decent
> clients.  Given how thin the uplink is, it's not too hard to use it all
> regardless of RTT, particularly with several active connections.

I do not know if I can release the results from the current experiment we 
are running. So I cannot give exact numbers. We do see improvement on 
download speed averaged across all ISPs. The improvement for some 
participating ISPs can be much larger than the global average, supporting 
your aforementioned that there can be substantial local improvement. The 
implication on ISP incentive will be an interesting issue. The key, as you 
pointed out, is to "download go as fast." I think this is more likely to 
be achievable.

Richard

---

From: Stanislav Shalunov <[email-masked]>
Date: Sat, 2 Aug 2008 21:11:35 -0700

On Aug 2, 2008, at 8:31 PM, Y. R. Yang wrote:
> We do see improvement on
> download speed averaged across all ISPs.

If the average download speed across all users increases, then the  
total upload speed increases.  This means there was room for it to  
increase.  With good use of transport, there should not be much room.   
How many upload slots do you use?  Is there an upload rate limit?

> The improvement for some
> your aforementioned that there can be substantial local improvement.

Sure.  Some ISPs have faster uplinks than average, and localizing will  
concentrate these on other users at the same ISP.  This means, though,  
that ISPs with slower uplinks will suffer.

> The implication on ISP incentive will be an interesting issue.

I'm not sure I get the connection.  The ISP incentive with flat rate  
is lower expenses.  With per-bit charges to the end-user means fewer  
irate users who got a huge surprise bill.  Right?

--
Stanislav Shalunov

---

From: "Y. R. Yang" <[email-masked]>
Date: Sun, 3 Aug 2008 00:41:31 -0400 (EDT)

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

> If the average download speed across all users increases, then the total
> upload speed increases.  This means there was room for it to increase.  With
> good use of transport, there should not be much room.  How many upload slots
> do you use?  Is there an upload rate limit?

There are scenarios where sum of uplink capacity (assuming full 
utilization by transport) is not the bottleneck of the aggregated 
throughput, for example, due to block availability or when you have more 
seeds. A client may get its content faster from faster seeds (with faster 
uplinks) than from slower seeds. Does this make sense to you? In terms of 
upload slots and upload rate limit, it is Pando specific, so I am not sure 
I can say it here. I will be happy to discuss offline, with Laird, though.
 
> >The improvement for some participating ISPs can be much larger than the 
> >global average, supporting your aforementioned that there can be 
> >substantial local improvement.
> 
> I'm not sure I get the connection.  The ISP incentive with flat rate is lower
> expenses.  With per-bit charges to the end-user means fewer irate users who
> got a huge surprise bill.  Right?

I was referring to ISP guidance to improve not only its network expense 
but also application performance. As you pointed out, faster ISPs benefits 
by guiding for localizaing, and slower ISPs may need to balance between 
transit costs and application performance (by pointing to outside). This 
is the incentive issue I was referring to. Believe or not, some ISPs do 
care a lot about giving guidance to improve application as well, as we see 
in the test :-)

Richard

---

From: "Y. R. Yang" <[email-masked]>
Date: Sun, 3 Aug 2008 01:14:57 -0400 (EDT)

> but also application performance. As you pointed out, faster ISPs 
> benefits by guiding for localizing, and slower ISPs may need to balance 
> between transit costs and application performance (by pointing to 
> outside). This is the incentive issue I was referring to. Believe or 
> not, some ISPs do care a lot about giving guidance to improve 
> application as well, as we see in the test :-)

An addition. I should not say "some ISPs". All ISPs we worked with cared a 
lot about not only about usage of network resources but also P2P 
application performance. I guess they believe ISPs giving good guidance 
prosper, or they were worried about our scrutiny :-)  We were quite 
surprised at some ISP configurations initially. It turned out that ISPs 
knew a lot more about their networks than we did, and such configurations 
appeared to be good tradeoffs between ISP and application objectives. I 
wish we could release some of such interesting configurations. I am not 
sure this will be ture in large-scale deployment. But there is some chance 
there.

Richard

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 4 Aug 2008 15:40:27 -0400

> I was referring to ISP guidance to improve not only its 
> network expense but also application performance. As you 
> pointed out, faster ISPs benefits by guiding for localizaing, 
> and slower ISPs may need to balance between transit costs and 
> application performance (by pointing to outside). This is the 
> incentive issue I was referring to. Believe or not, some ISPs 
> do care a lot about giving guidance to improve application as 
> well, as we see in the test :-)

This is certainly true...

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 4 Aug 2008 15:40:28 -0400

> WRT asking about sources other than yourself, I'm fine either 
> way, because the tracker can get the information from the peers.

I would agree, and would venture that ISPs would probably not want to
know this information either.

Jason

---

From: "Stas Khirman" <[email-masked]>
Date: Tue, 5 Aug 2008 23:42:19 -0700

> amount of
[Stas Khirman] 
I believe that both of you are probably correct - accordingly to P4P test
descriptions I hear, it performed in relatively small files. For those
files, when download time is under 15-20 min, detection of fast connections
is critical for average download speed.

As shown in number of papers (I can dig for references if needed) for large
file downloads (at least 1-2h total download time), initial peer selection
is less critical, as peers will find (eventually) speedy connections (it
depends not only on the local congestion, but, for example, on corresponding
peer availability).

In my personal testing on localization, download speed differs only in the
first 10-15 minutes of download (my test wasn't academic, just run for few
"piratebay"-type torrents using a proxy tracker that returns peers from one
large US DSL provider)

My guess is that ALTO "advise" will give significant benefits for end-users
for 
- P2P streaming where bootstrap is critical
- downloads for 100Mb and under

---

From: Lars Eggert <[email-masked]>
Date: Wed, 6 Aug 2008 13:57:20 +0300

On 2008-8-3, at 3:10, ext Richard Alimi wrote:
> its PID (a la DHCP).
(...)
>   ISPs with many subscribers may need this to be UDP.

I'm not convinced that the flow- and congestion-control mechanism  
required for a UDP-based protocol would be lighter-weight than simply  
using TCP.

Lars

---

From: Richard Alimi <[email-masked]>
Date: Wed, 6 Aug 2008 08:31:38 -0400

> required for a UDP-based protocol would be lighter-weight than simply

That is a good consideration.  In this case, both the request and reply are 
small (1 packet each), and the query only needs to be done once (at 
application startup).  If a response is not received, it can be retried 
periodically.

You're right that for more queries whose requests/responses are larger or need 
to be done much more frequently UDP may not be worth it.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 6 Aug 2008 16:35:46 +0300

> application startup).  If a response is not received, it can be  

I don't think we know enough about the types of queries we're talking  
about to be sure they request and esp. the response will fit in a  
single packet, or exactly when and how often transactions would take  
place.

Lars

---

From: Richard Alimi <[email-masked]>
Date: Wed, 6 Aug 2008 10:14:28 -0400

> single packet, or exactly when and how often transactions would take

Right - this was in reference to a specific query in the P4P protocol we're 
working on, but the details of that aren't necessarily directly relevant to 
ALTO at this stage :)

The overall point was that some queries are better as UDP, and some are better 
as TCP.

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 6 Aug 2008 07:30:18 -0700

>>> required for a UDP-based protocol would be lighter-weight than  

step up a level: it seems there is a multi-dimension consideration  
space.
light-weight may be one dimension.
other dimensions;
- head-of-line blocking (by TCP, that someone may not like).
- any future need for sending mcast pkts?
- transaction vs connection
- implementation maturity
- etc.

> I don't think we know enough about the types of queries we're  
> talking about to be sure they request and esp. the response will fit  
> in a single packet, or exactly when and how often transactions would  
> take place.
>
> Lars

conventional wisdom says that in case of uncertainty: slow start.
i.e. using what one has now to get ball rolling, while learn more  
about the the new space (to potentially moving to a new design later).
pros: easier start, lower risk
cons: possibility of getting stuck in a sub-optimal solution

Lixia

---

From: "Ye WANG" <[email-masked]>
Date: Wed, 6 Aug 2008 10:41:26 -0400

> depends not only on the local congestion, but, for example, on
[Ye (Yale)]
This is an interesting issue.  Actually, we were considering using a large
file (1GB movie, etc) in the field test to verify this case.  I think this
can be done in the near future.
In addition to file size, do you think the swarm size (number of concurrent
downloadings/seedings) also matters?  It could take longer time to gossip
faster neighbors if there are millions of peers in a swarm.  Anyway, most
swarms are relatively small.  From the results of the field tests, we see
larger download rate improvements for larger swarms.
Another observation we have is that faster peers could have larger
benefits.  ALTO advise is more critical to faster peers because users using
new access techniques are usually minority and may not be easy to find each
other.  As a result, although fater peers are potentially able to download
1GB in 30 minutes, the gossip process would introduce 30 minutes overhead.

> - downloads for 100Mb and under

[Ye (Yale)]
We may probably add two items:
- downloading in large swarms (e.g., 100,000+ peers)
- with faster network access