Subject: [p2pi] why i hummed no

From: <[email-masked]>
Date: Tue, 29 Jul 2008 12:47:53 +0100

Chairs asked for feedback from the no's , so here is mine
 
I think the general problem space - peer to peer (overlay) networks making routing choices that have bad effects on the lower layers is a very big and important problem
 
I think it is very important that we understand what solutions we should be working towards very well as I would hate to see bright and motivated people wasting time working on the wrong things, as this could divert effort from better solutions
 
my concern is that an oracle approach might not be terribly helpful
 
neither the p2p ap or the network have any reason to trust each other and the goals they are trying to achieve are likely to be different - how do i know you are telling me the highest bandwidth not the lowest cost choice?
 
the information recieved could be used in ways to harm the network - deliberatly choosing the non-preferred routes
 
the information might influenece the p2p application, but if the actual bandwidth (or lowest delay or lowest jitter etc etc) available from a non-preferred peer is higher than that then the non-preferred peer will be used, therefore analysis is required to try and quantify the likely benefit of such a scheme. there needs to be good corrolation between the oracle output and the p2p needs.
 
To really do the path choice thing sensibly in my mind requires dynamic information which can not be obtained from an oracle. Indeed from a provider perspective, this dynamic infomation could be more/as important also - I would want to direct you to lightly loaded links as directing you to a cheap, short high bandwidth but congested link is likely to do me more harm as well
 
I would like to see these issues considered better before rushing into solution space
 
Louise

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

---

From: "Damien Saucez" <[email-masked]>
Date: Tue, 29 Jul 2008 14:34:15 +0200 (CEST)

Louise,

Thanks for your feedback.

comments are inline.

> I think the general problem space - peer to peer (overlay) networks making
> routing choices that have bad effects on the lower layers is a very big
> and important problem
>
> I think it is very important that we understand what solutions we should
> be working towards very well as I would hate to see bright and motivated
> people wasting time working on the wrong things, as this could divert
> effort from better solutions
>
> neither the p2p ap or the network have any reason to trust each other and
> the goals they are trying to achieve are likely to be different - how do i
> know you are telling me the highest bandwidth not the lowest cost choice?
>
of course, this is why it should be optional. It is not a good point for
the provider to give inaccurate information. Indeed, eventually, the
client will remark that performances are better (with some application
level feedback) while not using the oracle and will decide to stop using
the oracle -> goto step 0!

> the information recieved could be used in ways to harm the network -
> deliberatly choosing the non-preferred routes
>
That is true, and must be added in the requirements. But systematically
using a bad path is already possible thanks to looking glasses,
measurements and other useful tools.

> the information might influenece the p2p application, but if the actual
> bandwidth (or lowest delay or lowest jitter etc etc) available from a
> non-preferred peer is higher than that then the non-preferred peer will be
> used, therefore analysis is required to try and quantify the likely
> benefit of such a scheme. there needs to be good corrolation between the
> oracle output and the p2p needs.
>
IMHO, the main point for the WG is to standardize a way to communicate,
the optimization will depends on the implementation. And it could even
open a new market with different third parties offering oracle systems
(?).

> To really do the path choice thing sensibly in my mind requires dynamic
> information which can not be obtained from an oracle.
Why dynamic information are not possible with an oracle? We did dynamic
path selection with IDIPS/LISP and it works fine.
> Indeed from a
> provider perspective, this dynamic infomation could be more/as important
> also - I would want to direct you to lightly loaded links as directing you
> to a cheap, short high bandwidth but congested link is likely to do me
> more harm as well
>
sure, the information is important for both so why not combine them in a
black box a-la oracle? Seems not stupid for me to have client sending
information to the oracle and the operator doing the same to the oracle.
The oracle just combine information from different sources and provide
this information later to who needs it (note: the oracle must take care of
not being a source of information leakage between the different worlds for
economical and privacy reasons).
> I would like to see these issues considered better before rushing into
Except the security point you mentioned, the points have already been
studied, you can find a lot of good papers talking about that.
> Louise
Cheers,

Damien Saucez

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 13:38:42 +0100

I too was one of those who "vehemently hummed" no at the BoF. Several people (including some ADs) seemed to seek to characterise those of us that hummed no as not believing that there was any sort of problem to be worked on.
 
I feel it is important to highlight that this is NOT because I believe there is no problem to be addressed here. Nor is it because I think the IETF is not able to do work in this space. My main objection is rather that the draft charter for this BoF could be (possibly unfairly) paraphrased as "wouldn't it be nice to have an entity in the network that we could ask lots of random questions...".
 
As Louise said below there are all sorts of potential problems with this approach. Not least the fact thaat the optimisation from the point of view of the network operator is likely to be VERY different from that of the end-user. Furthermore it seems that P2P apps such as BitTorrent are already producing near-optimal results from the point of view of the end-user and it is definitely not clear that an oracle could improve on these.
 
The overall sense I picked up from this BoF was that a group of people had already decided that the best solution was an oracle and this BoF was menat to just ratify that decision.
 
Having said all that I do want to encourage people to work on solutions to the "P2P problem" (note the " "...). I think much of this work could perhaps be done in the IRTF (as Tim Sheppard pointed out there is a very "researchy" feel to a lot of the stuff we saw presented). Once we have a really clear idea of the potential use cases for an oracle, an idea of how you can incentivise both user and ISP in such a way that any information can be trusted and if the information is only that which changes relatively slowly (e.g topology, price and nature of any interconnects) then it might be worth coming back to try again.
 
Toby Moncaster

________________________________

From: [email-masked] on behalf of [email-masked]
Sent: Tue 29/07/2008 12:47
To: [email-masked]
Subject: [p2pi] why i hummed no

Louise

---

From: Philip Levis <[email-masked]>
Date: Tue, 29 Jul 2008 13:52:04 +0100

On Jul 29, 2008, at 1:38 PM, <[email-masked]> wrote:

>  Furthermore it seems that P2P apps such as BitTorrent are already  
> producing near-optimal results from the point of view of the end- 
> user and it is definitely not clear that an oracle could improve on  
> these.

This is decidedly untrue. Ono, one of the mentioned approaches that  
uses topology information to choose peers, achieves a 31-207%  
improvement in download rates.[1]

Phil

[1] David R. Choffnes and Fabián E. Bustamante. Taming the Torrent: A  
practical approach to reducing cross-ISP traffic in P2P systems, To  
appear in Proc. of ACM SIGCOMM 2008, August 2008.
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Ulaş C. Kozat" <[email-masked]>
Date: Tue, 29 Jul 2008 05:52:48 -0700

One place where Oracle would do better than P2P apps is wide-area wireless
IP networks where probing and measuring between peers might be quite
expensive in terms of power and bandwidth, yet operators already have a good
idea of what are available inside their networks.

Ulas

On Tue, Jul 29, 2008 at 5:38 AM, <[email-masked]> wrote:

> I too was one of those who "vehemently hummed" no at the BoF. Several
> people (including some ADs) seemed to seek to characterise those of us that
> hummed no as not believing that there was any sort of problem to be worked
> on.
>
> I feel it is important to highlight that this is NOT because I believe
> there is no problem to be addressed here. Nor is it because I think the IETF
> is not able to do work in this space. My main objection is rather that the
> draft charter for this BoF could be (possibly unfairly) paraphrased as
> "wouldn't it be nice to have an entity in the network that we could ask lots
> of random questions...".
>
> As Louise said below there are all sorts of potential problems with this
> approach. Not least the fact thaat the optimisation from the point of view
> of the network operator is likely to be VERY different from that of the
> end-user. Furthermore it seems that P2P apps such as BitTorrent are already
> producing near-optimal results from the point of view of the end-user and it
> is definitely not clear that an oracle could improve on these.
>
> The overall sense I picked up from this BoF was that a group of people had
> already decided that the best solution was an oracle and this BoF was menat
> to just ratify that decision.
>
> Having said all that I do want to encourage people to work on solutions to
> the "P2P problem" (note the " "...). I think much of this work could perhaps
> be done in the IRTF (as Tim Sheppard pointed out there is a very "researchy"
> feel to a lot of the stuff we saw presented). Once we have a really clear
> idea of the potential use cases for an oracle, an idea of how you can
> incentivise both user and ISP in such a way that any information can be
> trusted and if the information is only that which changes relatively slowly
> (e.g topology, price and nature of any interconnects) then it might be worth
> coming back to try again.
>
> Toby Moncaster
>
> routing choices that have bad effects on the lower layers is a very big and
> important problem
>
> I think it is very important that we understand what solutions we should be
> working towards very well as I would hate to see bright and motivated people
> wasting time working on the wrong things, as this could divert effort from
> better solutions
>
> used, therefore analysis is required to try and quantify the likely benefit
> of such a scheme. there needs to be good corrolation between the oracle
> output and the p2p needs.
>
> information which can not be obtained from an oracle. Indeed from a provider
> perspective, this dynamic infomation could be more/as important also - I
> would want to direct you to lightly loaded links as directing you to a
> cheap, short high bandwidth but congested link is likely to do me more harm
> as well
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 29 Jul 2008 08:12:26 -0500

> Chairs asked for feedback from the no's , so here is mine

Louise: Thank your for the time and feedback.  More inline.

> I think the general problem space - peer to peer (overlay) networks
> making routing choices that have bad effects on the lower layers is a
> very big and important problem

OK.

> neither the p2p ap or the network have any reason to trust each other
> and the goals they are trying to achieve are likely to be different -
> how do i know you are telling me the highest bandwidth not the lowest
> cost choice?

That is a valid concern, but arguably can be solved by the
application not trusting the network's guidance if over a sustained
period of time such a guidance does not yield any measurable
benefits.

> deliberatly choosing the non-preferred routes

If an application deliberately chooses non-preferred routes even
in the face of guidance from an ALTO service, then the network
is no worse off than the same application making random choices
biased towards non-preferred routes when an ALTO service is
not present.

> the information might influenece the p2p application, but if the
> actual bandwidth (or lowest delay or lowest jitter etc etc) available
> from a non-preferred peer is higher than that then the non-preferred
> peer will be used, therefore analysis is required to try and quantify
> the likely benefit of such a scheme. there needs to be good
> corrolation between the oracle output and the p2p needs.

I believe that over time, if the application finds that the ALTO
service is not delivering the goods, it will simply stop using
it.  The ALTO service has always been defined as optional (the
problem-statement discusses this as well.)

> To really do the path choice thing sensibly in my mind requires
> dynamic information which can not be obtained from an oracle. 

Fair enough.  This point was also made by others, including Lars.
But before going down further, what exact dynamic information
did you have in mind?  During various list discussions it has
been pointed out that using information that changes on microscopic
timescales will not be part of a ALTO anyway.

> I would like to see these issues considered better before rushing

Sure.  Thanks for your consideration.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 29 Jul 2008 09:15:27 -0400

I did not hum no during the session, but I have to say I was thinking 
the same thing as expressed by Toby & Louise:  people understand there 
is a problem here, but don't necessarily agree with the work being 
proposed to solve it.

Of course, the immediately following thought is:  if one doesn't think 
this is the right, IETF-sized chunk to chop off and solve, what is the 
better alternative?

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: David R Oran <[email-masked]>
Date: Tue, 29 Jul 2008 09:20:16 -0400

Small point embedded, banging a bit more on the point I made at the  
mic about discovery...

> biased towards non-preferred routes when an ALTO service is
This is true as long as the peer/cache/service discovery functions  
don't migrate into the ALTO service/server domain. Once you start  
depending on the ALTO server to find peers, caches, etc., they become  
critical infrastructure for effective operation of the P2P system.  
this may be OK for ALTO servers that are under the same administrative  
authority as the P2P application itself, but not ok when the ALTO  
servers have "tussle" with the application/resource owners.

It may be useful to build some kind of explicit domain-based  
partitioning of these things into the ALTO architecture, so that a  
client can ascertain when there is mutual trust among the three  
(possibly more?) interested parties: the application/resource  
provider, the communication capacity provider(s), and the client.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 29 Jul 2008 08:29:37 -0500

[email-masked] wrote:
> I feel it is important to highlight that this is NOT because I 
> believe there is no problem to be addressed here. Nor is it because I
> think the IETF is not able to do work in this space.

Toby: Thank you for your feedback.

> My main objection is rather that the draft charter for this BoF could
> be (possibly unfairly) paraphrased as "wouldn't it be nice to have an
> entity in the network that we could ask lots of random
> questions...".

That was not the intent of the charter.  It is clear that we
have to work some more on it.

> producing near-optimal results from the point of view of the end-user
> and it is definitely not clear that an oracle could improve on these.
> 
I don't think that is the case, though.  Ulas pointed out the work
on Ono and I have seen other work on BitTorrent deriving benefit from
topological information.

> The overall sense I picked up from this BoF was that a group of 
> people had already decided that the best solution was an oracle and 
> this BoF was menat to just ratify that decision.

Maybe the term "oracle" is not the right connotative word here.
It seems to hold a lot of context for people.

We deliberately wanted to stay out of discussing solutions and
simply agree on the problem statement first.  But perhaps the
charter did not quite reflect that.  Clearly, we need to do
some more work here.

Thanks,

- vijay

---

From: Bruce Davie <[email-masked]>
Date: Tue, 29 Jul 2008 09:39:13 -0400

I really think we need to have people looking at experimental data  
rather than using their intuition as to whether an Oracle might or  
might not help. The paper cited below is one good example of data  
that support the hypothesis that an Oracle *could* improve the  
overall situation. Another reference is this one:

Improving Traffic Locality in BitTorrent via Biased Neighbor Selection
Bindal, R.; Pei Cao; Chan, W.; Medved, J.; Suwala, G.; Bates, T.;  
Zhang, A.
26th IEEE International Conference on Distributed Computing Systems,  
2006.

I'm sure the folks at Pando can point to some of their experimental  
data that also shows an Oracle can work effectively.

Note also that as long as the oracle makes performance *no worse* for  
the end user, while also improving the efficiency of network  
utilization for the SP, it would still be worth deploying the  
oracles. And as others have said, as long as they are optional, the  
SP will have a strong incentive to deploy oracles that improve end- 
user performance as well as the efficiency or cost of the SPs network.

Also note that the point of the WG, if chartered, would be to  
standardize an *interface* for talking to an oracle, which would  
allow plenty of room for future algorithms to make oracles work  
better. But let's not pretend that this is a totally wide open  
research problem - the research has been going on for many years.

With vendors already producing oracles, it seems very timely for the  
IETF to standardize the interface by which clients talk to oracles,  
while allowing for innovation in how exactly the oracles work.

Bruce Davie

On Jul 29, 2008, at 8:52 AM, Philip Levis wrote:

>> user and it is definitely not clear that an oracle could improve  
>> on these.
>
> [1] David R. Choffnes and Fabián E. Bustamante. Taming the Torrent:  
> A practical approach to reducing cross-ISP traffic in P2P systems,  
> To appear in Proc. of ACM SIGCOMM 2008, August 2008.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Jul 2008 15:04:00 +0100

Disclaimer: I have been in other meetings all day and I don't know what 
was presented and discussed in your meeting. I have not seen a charter 
proposal.

However, the issue that Louise raised is something that I have also 
brought up in other contexts. I see the oracle approach being suggested 
and worked on in several places. I think it is a valid approach, but 
people need to understand that its not a panacea. In particular, it is 
very hard for me to imagine that any one point in the network has 
up-to-the-millisecond accurate information about congestion. As 
described in the P2PI workshop, the P2P applications have a number of 
factors that they have to consider when picking a peer. These include 
health of the pool that contains the information, diversity, various 
incentives related to trading pieces of files, etc. As a result, the 
oracle answer can only be ONE factor to consider, not the deciding 
factor. Perhaps a tie-breaker among otherwise equivalent peer choices. 
And any decision needs to be followed up by realtime tracking as the 
application observes bandwidth and congestion situation with the chosen 
peers. A chosen peer may have to be abandoned and a new one chosen.

Also, I like the transport mechanisms (TANA) more than oracle approach, 
because there is a significant difference in deployability. Things you 
can do on your own in the applications are faster to deploy than 
something that requires support in the applications and networks (see 
also draft-arkko-p2pi-incentives).

I was not in the room to hum either way. But for the record, I think it 
makes a sense for the IETF to develop a standard for an oracle 
functionality -- but for a very specific information, and with explicit 
guidance about how such functionality should and should not be used. I 
think this is needed not just for P2P but for other bandwidth hungry 
applications (video, surveillance, etc.). I think this is a good time 
for us to develop a toolbox to help future applications in this space, 
and an oracle can be one tool in that box. Just do not attempt to do too 
much, or claim too broad applicability.

Jari

---

From: Laird Popkin <[email-masked]>
Date: Tue, 29 Jul 2008 10:07:50 -0400

To second this, P4P's traffic localization results in dramatic  
improvements in performance. For example, Verizon reported over 3x  
speedups in download speed for FIOS customers.

The p2p networks do a very good job of optimizing performance over  
time. The issue is that it can take a very long time (e.g. hours) to  
discover and converge on the optimal set of peer data sources, while  
good network guidance can give a very good starting point, resulting  
in much better performance much sooner.

- LP

---

From: songhaibin 64081 <[email-masked]>
Date: Tue, 29 Jul 2008 22:30:36 +0800

Yes. Probing are not always true. Operator know its network exactly.

-Song Haibin

---

From: Laird Popkin <[email-masked]>
Date: Tue, 29 Jul 2008 10:42:27 -0400

Addressing the concern that the ISP and the P2P network's agendas  
might not align, which is certainly a risk, there is an belief that in  
general the "closest" peers in the network sense are also the "best"  
peers for the p2p network. This isn't true in every case, but it's  
true enough on average that we're seeing in testing (in the P4P  
Working Group) that localizing traffic yields  benefits for both the  
ISP (e.g. 50% transit reductions) and the P2P network (e.g. up to 3x  
speedups). Of course, there are cases where closest peers aren't best  
peers, but as long as closer=better most of the time, localizing data  
transfers is good.

One thing to keep in mind is that from the p2p network perspective,  
the "network guidance" is optional, helpful information to improve  
network performance, working in addition to whatever else the p2p  
networks already do.

If an ISP publishes harmful guidance in order to hurt p2p networks,  
p2p networks will figure it out and ignore that ISP's guidance. If an  
ISP chooses not to provide any guidance, they'll perform as they do now.

In terms of static vs. dynamic guidance, I think that both are  
valuable, but IMO it's easier to focus on relatively static guidance  
first. There's a lot to be gained even with a very simple, relatively  
static guidance such as knowledge of network interconnects within and  
between ISPs. Also, keep in mind that once the oracle affects which  
peers are connected to each other, the oracle is done, and the p2p  
networks manage the actual data transfers, responding to the real-time  
statistics such as actual throughput, congestion, etc.

That being said, integrating real-time link statistics might be very  
interesting. For example, if there's a link outage between two cities,  
the oracle could stop telling peers on either city to talk to people  
in the other city. There's also an interesting (IMO) area of  
optimization where the guidance can be time-based, so the oracle can  
be used to shape p2p traffic differently during the day time and nigh  
ttime, etc.

- LP

On Jul 29, 2008, at 7:47 AM, <[email-masked]> wrote:

> making routing choices that have bad effects on the lower layers is  
> a very big and important problem
>
> I think it is very important that we understand what solutions we  
> should be working towards very well as I would hate to see bright  
> and motivated people wasting time working on the wrong things, as  
> this could divert effort from better solutions
>
> neither the p2p ap or the network have any reason to trust each  
> other and the goals they are trying to achieve are likely to be  
> different - how do i know you are telling me the highest bandwidth  
> not the lowest cost choice?
>
> actual bandwidth (or lowest delay or lowest jitter etc etc)  
> available from a non-preferred peer is higher than that then the non- 
> preferred peer will be used, therefore analysis is required to try  
> and quantify the likely benefit of such a scheme. there needs to be  
> good corrolation between the oracle output and the p2p needs.
>
> dynamic information which can not be obtained from an oracle. Indeed  
> from a provider perspective, this dynamic infomation could be more/ 
> as important also - I would want to direct you to lightly loaded  
> links as directing you to a cheap, short high bandwidth but  
> congested link is likely to do me more harm as well
>

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 16:03:02 +0100

From: [email-masked] on behalf of Philip Levis
Sent: Tue 29/07/2008 13:52
To: Moncaster,T,Toby,CXR9 R
Cc: [email-masked]
Subject: Re: [p2pi] why i hummed no

<LOUISE> ta

(based on very quick reading - i think it deserves more) it achieves this improvement over a scheme that uses a random selection of peers

What we need to see is if network provided information can give an improvement over what p2p systems can achieve all by themselves without nec assuming they use a random selection. for example I have heard that some p2p systems look at the IP address and try to determine nearness.  - we should knw the difference between best of both breeds </louise>

Phil

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 16:03:59 +0100

OK I just realised that perhaps i also may have a different idea of what/where the real problem is
 
yip,  reducing overall traffic distance will reduce congestion, and keeping within an ISP can control inter-connect costs, but if as a network provider the congestion bottlenecks are near the access then having such a scheme that improves nearness won't help my network resource management problem - the p2p system might work better but the network operators (and their non-p-2-p customers) could still be complaining?
 
Near the access= roughly at the shared dslam, which was what was postulated within the tsvarea meeting just after the bof

From: Laird Popkin [mailto:[email-masked]]
Sent: Tue 29/07/2008 15:42
To: Burness,AL,Louise,CXR9 R
Cc: Laird Popkin; [email-masked]
Subject: Re: [p2pi] why i hummed no

- LP

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 29 Jul 2008 10:40:36 -0500

[email-masked] wrote:
> (based on very quick reading - i think it deserves more) it achieves
> this improvement over a scheme that uses a random selection of peers

Sure.  A portion of their data includes a random selection of
nodes, including those supporting Ono and those that do not.

But...

> What we need to see is if network provided information can give an
> improvement over what p2p systems can achieve all by themselves
> without nec assuming they use a random selection. for example I have
> heard that some p2p systems look at the IP address and try to
> determine nearness.  - we should knw the difference between best of
> both breeds </louise>

... they also run an experiment where they provide data on Ono-
only peers (see Figure 7.)  These peers outperform the randomly
selected nodes by a very wide margin.

Thanks,

- vijay

---

From: Laird Popkin <[email-masked]>
Date: Tue, 29 Jul 2008 11:50:12 -0400

This is correct - localizing transit reduces transit consumption (i.e.  
links within and between ISPs), but doesn't change (much) the "last  
mile" consumption because ultimately the same users are uploading and  
downloading the same content. Caching is (IMO) a part of the picture,  
because any data that is delivered by a cache server is data that  
users didn't have to upload.

- LP

On Jul 29, 2008, at 11:03 AM, <[email-masked]> wrote:

> yip,  reducing overall traffic distance will reduce congestion, and  
> keeping within an ISP can control inter-connect costs, but if as a  
> network provider the congestion bottlenecks are near the access then  
> having such a scheme that improves nearness won't help my network  
> resource management problem - the p2p system might work better but  
> the network operators (and their non-p-2-p customers) could still be  
> complaining?
>
> Near the access= roughly at the shared dslam, which was what was  
> postulated within the tsvarea meeting just after the bof
>

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 29 Jul 2008 09:10:53 -0700

Note: I was not at the BOF, but do have some thoughts based on the  
current discussion:

On Jul 29, 2008, at 8:03 AM, <[email-masked]> <[email-masked] 
 > wrote:

> postulated within the tsvarea meeting just after the bof

In this case, the oracle controlled by the ISP can still help:   
Namely, I wonder how much the succesful performance of BitTorrent etc  
rest on leeching of university and other related hosts where you don't  
have congestion on the uplink.  Thus by diverting even your customers  
away from peering with other internal customers, the ISP benefits as  
they reduce their real network cost in this case, shifting traffic  
onto the less congested downlink.

The problem comes in that each ISP wants to be as much of a leech as  
possible:  Your customer wants the file, so you need to provide the  
download for them.  You are an ISP, thats what you do.

But the UPLOAD is NOT benefiting your customer, only other ISPs'  
customers.  In fact, if you have congestion in the uplink direction,  
the UPLOAD is penalizing your other customers.  Hmm, "Help other  
people's customers while hurting my own?"  I know what my reaction to  
that would be.

Thus even localization is not necessarily in the benefit of the ISP,  
depending on where the congestion is: you want to ANTI-localize if its  
the CMTS/DSLAM where congestion is occuring: stick someone else with  
that bandwidth cost, because at this time, it may cost you MORE to  
serve the data internally rather than externally.

This suggests the limits of ALTO if the ISP is controlling the oracle  
(rather than a third party like Akamai in the "Taming the Torrent"  
paper):  You get the tragedy of the commons occurring if the ISP's  
uplink costs are, at this moment, higher than other ISPs' costs, and  
so effectively you change the leeching problem from the user level to  
the ISP level, but magnify it because now there is a lot more bits/ 
money at stake when you aggregate things.

Great: lets instead of just arranging a conflict between the ISP and  
content provider, create inter-ISP conflicts as well.

Rather, the idea system for the ISP would be to "Leech and cache":   
Limit/eliminate the upload from the end user altogether, and have a  
large local cache for the download.

This is why I think that focusing on ALL P2P is, IMO, a mistake: the  
focus should be on CACHEABLE bulk data: where the ISP can cache the  
traffic to serve other customers in their network, without worrying  
about getting sued by the MPRIAA.  Caches don't have to be reliable in  
a P2P system (if they go down, you lose performance, unlike an inline  
HTTP cache) but when present can be a huge potential win for both the  
customer AND the ISP.

For bulk data P2P, without a cache, each customer needs to, on average  
over everybody, download N bytes and upload N bytes.  I'm sure we can  
all agree that this is grossly inefficient, especially for popular  
files.

Yet with a cache, each customer needs to download N bytes, but each  
customer uploads 0, and the ISP as an aggregate only needs to download  
N and upload N bytes across its connection, which is a huge win, both  
for performance (the customer is almost always getting the cached  
data, no congestion on the last mile uplink, no congestion on the  
general uplink) and for cost.

And its relatively easy to do.  Use ALTO or a similar program to  
direct local clients to that cache.  Or, heck, there's probably a way  
to play DNS games:  Lookup "hashcode.p2pcache.com" returns the IPs for  
nodes which have this data and are local: ISPs can redirect to their  
own oracle, or go to the central oracle if they don't support it.

The problem I have, however, is this quickly looks very similar to a  
CDN.  Because it is, just a CDN that's decentralized and can be more  
available as a public resource.

This is why, overall, I'm highly skeptical of commercial P2P  
distribution for bulk data: the better the system can work in terms of  
minimizing TOTAL system costs (rather than just minimizing content- 
provider costs while shifting and magnifying ISP's costs), the more it  
looks like Akamai!

And each trick you do to improve performance (eg, (ab)use DNS so you  
don't need a separate oracle protocol, reduce the uplink usage to 0 by  
only communicating data from caches rather than user end nodes, have  
the content provider pay for the cache to get it deployed, etc etc  
etc), the more it becomes a conventional CDN.

And this is why, if anything, I think the answer should be "No  
separate protocol":

Overload DNS if you want an oracle for topology discovery, just like  
"Taming the Torrents" does.  Forget ALTO.  Forget P4P.

Just pick an unregistered name, have a centralized oracle, and  
(optionally) have an RFC extension to DNS for responses which allow  
the local server to override or redelegate to the ISP's local oracle.

You get a system you can deploy today WITHOUT ISP cooperation, and  
that as ISPs want to cooperate, you can refine the results more.

Lacking ISP cooperation is probably a GOOD thing for commercial P2P,  
as you avoid the tragedy of the commons effect.

And for the pirated content, let Pirate Bay run the oracle.  Yes, such  
an oracle has a single point of failure for legal attack.  Thats  
hardly a bug in my opinion.

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 17:32:37 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay K. Gurbani
> Sent: 29 July 2008 14:30
> 

I had the same sense of the meeting as Toby and felt that it was a pity
the opportunity seemed to have been missed to charter work on what is
clearly accepted to be an important problem (notwithstanding Jon's
assertion that 'we'll be back').

I think to move forward it is necessary to narrow the scope of what sort
of questions an oracle can be expected to answer (coarse-grained
topology and nothing else?) and make that explicit in the charter.
Leaving that scoping for a WG to figure out will encourage lots of
debate post-WG formation and will hinder concrete progress, IMHO.

Mat

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 13:54:54 -0400

That's a good point to make.   Much of this work is to reduce the
overall impacts of P2P traffic on the ISP networks while also increasing
the end user performance.   It won't be possible to eliminate all
impacts of P2P as we're still delivering the same content to the end
user.  There's no silver bullet and individual ISPs will have different
preferences and needs.  

This is all a bit like BGP is today.  In the early days, BGP was almost
entirely trust based.   In response to accidents such as full table
leaks or de-aggregation, a number of safeguards were created over time.
Most of those are more about best practices than standards.  I believe
the same will ultimately apply in this context.  We'll have a hard
standard for the technology and best practices for handling behavioral
anomalies.  

Doug

---
Doug Pasko
PMTS - Principal Member of Technical Staff
Verizon Network and Technology
VC12W413
One Verizon Way, Basking Ridge, NJ 07920
Office: 908-559-1472  Cell: 703-930-7581

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Laird Popkin
Sent: Tuesday, July 29, 2008 11:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [p2pi] why i hummed no

- LP

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 14:30:03 -0400

I would agree with you that the ability to indicate the existence of P2P
caching resources at the application layer is an important function that
should not be overlooked.  If a carrier were looking to make available
caching resources, they'd need a simple and standard way to announce
their presence to the P2P systems they would support.   I would consider
this a feature in the overall approach since some ISPs would not
necessarily wish to deploy, manage and maintain P2P caches.  The legal
protections for caching you mentioned are unfortunately not necessarily
ironclad, nor would they apply in all countries.

I would disagree with abandoning the concept of ISP guidance for peer
selection.   In the first P4P field trial, Verizon was able to see
significant reductions in network usage by average distance traveled for
the P2P traffic tested.   In that example, Verizon has no ability
whatsoever to influence the flow of traffic between users on another
ISP's network.   If we were truly to come to an impasse on trust between
carriers, those results for internal ISP optimization are still more
than worth the effort.  

I don't believe the ISPs community as a whole would attempt to take the
actions you described.   That said, if there is enough concern that it
could happen, I think we should endeavor to build-in safeguards and
mechanisms to detect the abuse rather than abandon the potential
benefit.

Thanks
Doug

---
Doug Pasko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicholas Weaver
Sent: Tuesday, July 29, 2008 12:11 PM
To: <[email-masked]>
Cc: [email-masked]; Nicholas Weaver
Subject: [p2pi] Some thoughts on why I would hum no

On Jul 29, 2008, at 8:03 AM, <[email-masked]>
<[email-masked]

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 29 Jul 2008 12:09:25 -0700

Hello,

Let me try to summarize a few points I heard during the BOF presentation and
also that people have been making on the list.

Personally I think this group could use some kind of architecture document
or a section on some existing document that have pictures, functions, etc.
It seems people have different mental pictures and expectations of what the
ALTO solution is and their players.

Discovery of ALTO Service
=========================

* I believe there should a way to discover an ALTO Service in a network. Not
only I'm happy to reuse a IETF protocol but I also encourage it. But my
experience with many different P2P clients, overlay networks and others is
that things are already quite diverse and to help client developers and ISPs
we have to tell "use protocol Y to discover the ALTO Service". Or as
somebody else said :"there can be only one"...otherwise we will have
bootstrapping and interoperability problems

Discovery of Caches
===================

* _If_ you think caching is an important piece of the ALTO Solution that
could reduce bandwidth consumption in the upstream direction, then there
should be one recommended way to finding them (many are possible, but one
should be recommended). Again, it is all about interoperability and
standardization.

The discovery could be done by the clients, caches could be just like other
peers running P2P protocol and announced by the ALTO Service, or the client
could ask the ALTO Service "where is the nearest cache?". Some people
preference on which solution we should pursue.

Discovery of other "Stuff"
==========================

* I'm not sure how relevant is the discovery of media relays and others. I
was asked to summarize the discussion on the list and some people thought it
could be useful on this way, so it was in the presentation.

Personally I thought this was a contention issue.

Peer Selection
==============

* As long as we can agree that a service in the network (or through some 3rd
party) will provide a Peer Selection Service, the semantics of the
information passed can be a second step. Of course for interoperability
purposes we should have at least one identification of peer and metric that
everybody understand. This could be IP address and a number since we are
assuming this is an IP network.

But, as long as we agree that a service will be provided, the query response
protocol could be point to point, DHT based, or others.

Thanks,

Reinaldo

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 29 Jul 2008 12:11:41 -0700

On Jul 29, 2008, at 11:30 AM, <[email-masked]> <[email-masked] 

> carriers, those results for internal ISP optimization are still more

I think its more that the ISP has an unusual set of incentives:

You can build your oracles without ISP cooperation, you don't need ISP  
cooperation ("Taming Torrents" proved this), and with ISP cooperation  
it makes the incentives weirder:

There are cases where there IS no internal ISP optimization: rather it  
is in the ISP's interest to force ALL the traffic to come from  
elsewhere, depending on where congestion is occuring.  If you get  
congestion in the CMTS/DSLAM uplink, well, thats hurting all your  
other customers.

And its also:

You don't need a new protocol to build your oracles and distribute  
information, the existing DNS infrastructure can do just fine as a way  
of performing queries efficiently and effectively.  Query for  
{hashcode}.nonce.myip.p4pcache.com and return a list of IPs that are  
the peers you would be "best" provided with for the resource  
{hashcode}.  At the same time, this registers myip as being associated  
with {hashcode} as well.  [1]

If the ISP wishes, they can override the lookup for ...p4pcache.com  
should they wish a local oracle to have priority, so ISP cooperation  
can be used, but isn't required, in a system you can deploy today.

and:

The more economically viable a commercial bulk-data P2P system is at  
reducing aggregate costs, rather than just content provider costs, the  
more it looks like a CDN.  EG, the DNS sketch above is effectively how  
Akamai works (and "Taming the Torrents", so its (ab)using DNS in old  
and common ways, not new and different ways).  CDNs already know how  
to get good location information and how to distribute it, and how to  
put caches in the ISPs.

So why should the IETF invest resources in designing a system (ALTO)  
where:

a)  You can do it all for the client side (oracle query) by (ab)using  
DNS today in an already well-abused fashion.

b)  The CDNs already know how to get the information to construct a  
good oracle on the server side.

c)  Sees the biggest benefit for piracy-systems and commercial systems  
that are far less efficient than existing CDNs?  Because as soon as  
you add CDN-style caching into the basic P2P structure, you only  
bother talking to the local cache and let the cache delegate getting  
the data.

[1] The Joe-job potential is low, as even on set of HUGELY popular  
torrents, it would mean just a few SYNs per participant for just the  
"local" peers, so say 10 NEW peers/second * 10 SYNs/peer -> 100 SYN/ 
sec -> 8 kbps -> who cares?

---

From: "Y. R. Yang" <[email-masked]>
Date: Tue, 29 Jul 2008 15:53:21 -0400 (EDT)

Hi Nick,

Thanks a lot for your excellent points. Below are a few comments.

On Tue, 29 Jul 2008, 12:11pm -0700, Nicholas Weaver wrote:

> 
> On Jul 29, 2008, at 11:30 AM, <[email-masked]>
> <[email-masked]> wrote:
> 
> >
> cooperation ("Taming Torrents" proved this), and with ISP cooperation it makes

I would have to disagree with abandoning the more direct ISP information.

"Taming torrent" is using the preference of Akamai to guide traffic 
distribution. Akamai is not a neutral entity and has its own incentives 
(e.g., load balancing according to the congestion status of its *own* 
servers). A key question is whether Akamai can know ISP's preferences or 
try to help ISPs.

In terms of ISP incentives, in the P4P implementation and field tests, P2P 
can always override ISP information to both maintain application 
performance and to maintain "fairness". For example, in the implementation 
of current field test, P2P sets a large target for intradomain selection 
before interdomain selection.

> the incentives weirder:
> 
> There are cases where there IS no internal ISP optimization: rather it is in
> the ISP's interest to force ALL the traffic to come from elsewhere, depending
> on where congestion is occuring.  If you get congestion in the CMTS/DSLAM
> uplink, well, thats hurting all your other customers.
> 
> 
> And its also:
> 
> information, the existing DNS infrastructure can do just fine as a way of
> performing queries efficiently and effectively.  Query for
> {hashcode}.nonce.myip.p4pcache.com and return a list of IPs that are the peers
> you would be "best" provided with for the resource {hashcode}.  At the same
> time, this registers myip as being associated with {hashcode} as well.  [1]

Again, who runs p4pcache.com and whose preference does it reflect?
 
> If the ISP wishes, they can override the lookup for ...p4pcache.com should
> they wish a local oracle to have priority, so ISP cooperation can be used, but
> isn't required, in a system you can deploy today.
> 
> 
> and:
> 
> The more economically viable a commercial bulk-data P2P system is at reducing
> aggregate costs, rather than just content provider costs, the more it looks
> like a CDN.  EG, the DNS sketch above is effectively how Akamai works (and
> "Taming the Torrents", so its (ab)using DNS in old and common ways, not new
> and different ways).  CDNs already know how to get good location information
> and how to distribute it, and how to put caches in the ISPs.
> 
> 
> 
> 
> So why should the IETF invest resources in designing a system (ALTO) where:
> 
> a)  You can do it all for the client side (oracle query) by (ab)using DNS
> today in an already well-abused fashion.

Personally, I would prefer clean, extensible solutions, than abuses :-)
 
> b)  The CDNs already know how to get the information to construct a good 
> oracle on the server side.

My understanding is that the intention is to be good only for CDNs.

It is clear that the solution space is quite large. There are many 
research issues remaining. But I do see strong values in IETF standarzing 
some basic protcols.

Richard
 
> c)  Sees the biggest benefit for piracy-systems and commercial systems that
> are far less efficient than existing CDNs?  Because as soon as you add
> CDN-style caching into the basic P2P structure, you only bother talking to the
> local cache and let the cache delegate getting the data.
> 
> 
> [1] The Joe-job potential is low, as even on set of HUGELY popular torrents,
> it would mean just a few SYNs per participant for just the "local" peers, so
> say 10 NEW peers/second * 10 SYNs/peer -> 100 SYN/sec -> 8 kbps -> who cares?
>

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 29 Jul 2008 13:13:26 -0700

> before interdomain selection.

What my point is that you don't need to REQUIURE ISP cooperation, and  
that you are far better served building a system which is usable now  
without ISP cooperation, but where ISP cooperation can be grafted into  
the system cleanly as ISPs want to add their own support and their own  
weights.

> Again, who runs p4pcache.com and whose preference does it reflect?

The content provider(s) or a third party service, and the goal is to  
maximize aggregate performance.

EG, there are easy business models: "You give me a hashcode and a  
penny, and I'll provide the service for the hashcode.  And if the MPAA  
comes after me, I'll direct them to you".

If an ISP wants to provide more detail for their customers, they can  
(and should) impose their own responses.  This is one of the cases  
where lack of cryptographic signatures is a Good Thing (tm).

> Personally, I would prefer clean, extensible solutions, than  

I guess I don't really think of it as an abuse.

You want a service that can quickly return a set of IP addresses and  
auxiliary information for a hierarchically-addressed record, which is  
either generated locally if you have a local authority, or delegated  
to the proper remote authority.

Latency matters as well, you want it to take, if possible, only a  
single RTT to get a response.

And you want an easy to use API for programmers as well, available in  
as many languages as possible, so that every P2P program can use this  
with the absolute minimum amount of work.

At the same time, you want universal deployment of the oracle  
infrastructure to maximize the benefit.

So actually, I think we are in agreement in the need for a clean  
extensible solution, I just believe that the clean, extensible  
solution is already present in DNS.

> research issues remaining. But I do see strong values in IETF  

The actual weights for the oracle in the CDN case are to optimize  
things for the CDN.  But the basic raw data needed should be pretty  
much the same.  So why reinvent the wheel?

---

From: "Y. R. Yang" <[email-masked]>
Date: Tue, 29 Jul 2008 19:10:30 -0400 (EDT)

> the system cleanly as ISPs want to add their own support and their own 

I agree with the incremental deployment requirement. The P4P 
implementation and field tests do not require ISP cooperation in order to 
achieve incremental deployment. If a client is in an ISP with no ISP 
guidance, we use pure AS-locality peering first. The ASN number is from a 
public database. Inside the ASN, it is random peering, as we have no 
information and no guidance. We could use some geodistance database to 
approximate ISP guidance, but this is not very meaningful.
 
> The content provider(s) or a third party service, and the goal is to maximize
> aggregate performance.
> 
> EG, there are easy business models: "You give me a hashcode and a penny, and
> I'll provide the service for the hashcode.  And if the MPAA comes after me,
> I'll direct them to you".

In the on-going P4P field test, there is an application optimization 
engine running at Yale. It queries ISPs for ISP information. A P2P 
application (a Pando swarm) queries the application optimization engine to 
obtain guidance on how to select peers. I guess this model may fit into 
your third-party model (a swarm == a hashcode), although with different 
access protocols (you are trying to reuse DNS while the P4P field test is 
using a new protocol).

One key difference with your model is that the formulation of the 
optimization engine is to optimize ISP cost (for the joining client) while 
satisfying constraints on guaranteeing application performance (the 
aggregate performance you mentioned, I guess). By ignorging ISP cost, your 
model can avoid the problem of "misleading" by ISP information. But I 
consider this as an important opportunity missed on improving network 
efficiency.

> If an ISP wants to provide more detail for their customers, they can (and
> should) impose their own responses.  This is one of the cases where lack of
> cryptographic signatures is a Good Thing (tm).
> 

I am not sure the right mode is to return a set of IP addresses. Your 
model assumes that p2pcache.com maintains the state of the hashcode--it 
remembers those who queried. But this state may become obsolete when 
clients leave; neither does it have client bandwidth information, unless 
you add messages to update the state at p2pcache.com. In P4P field test, 
the query to application optimization engine includes aggregated swarm 
state information and returns weight matrix. Thus, it becomes more 
different from DNS and thus the new protocol.

> either generated locally if you have a local authority, or delegated to 
> the proper remote authority.
> 
> Latency matters as well, you want it to take, if possible, only a single RTT
> to get a response.

It will be better if it is smaller than one RTT. The application 
optimization engine response is cached at applications and thus reduces 
the delay.
 
> And you want an easy to use API for programmers as well, available in as many
> languages as possible, so that every P2P program can use this with the
> absolute minimum amount of work.

Sure.
 
> At the same time, you want universal deployment of the oracle infrastructure
> to maximize the benefit.

Sure. BTW: I would prefer to use the term "ALTO server" to "oracle". 

> So actually, I think we are in agreement in the need for a clean extensible
> solution, I just believe that the clean, extensible solution is already
> present in DNS.

I guess I think that it is different enough from DNS to justify a new 
protocol framework.
 
> The actual weights for the oracle in the CDN case are to optimize things for
> the CDN.  But the basic raw data needed should be pretty much the same.  So
> why reinvent the wheel?
> 

Our formulation is to optimize not only CDN, but ISP costs as well. It 
fits into enterprise network as well. So we need a new, extensible 
framework. Of course, if DNS overloading is the more feasible option, we 
sure can start from here.

Richard

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Jul 2008 10:23:54 +0100

Hi,

On 2008-7-29, at 15:04, ext Jari Arkko wrote:
> I was not in the room to hum either way. But for the record, I think  
> it makes a sense for the IETF to develop a standard for an oracle  
> functionality -- but for a very specific information, and with  
> explicit guidance about how such functionality should and should not  
> be used.

I agree with Jari, and said something along similar lines at the mike  
after the hum: The only reason I didn't hum for ALTO was that I  
believe the proposed scope is currently too broad. (And for the record  
I didn't hum against either.) I do believe we should charter something  
with a more limited scope.

What limited scope?

Although ALTO mostly focuses on the query/response protocol for  
information, we can't totally separate this from the kinds of  
information asked for and disseminated using ALTO. My litmus test is  
whether we can answer these questions for each piece of information  
that ALTO could carry:

    (1) Why is it not easy or cheap for the application
        to obtain this information in other ways?

    (2) What's the rough sketch for how an ALTO box would
        obtain this information in a way that is timely and accurate?

    (3) Are the incentives aligned such that it is beneficial
        for the entity who is paying for the ALTO box to do so,
        *and* for the apps to use it?

The only piece of information for which I have people seen giving  
reasonable answers to these questions is operator preference, as in  
"which peers would my ISP prefer I communicated with?"

I believe hat chartering ALTO at this time with an initial focus on  
that one bit of information would make sense. I could even see the  
charter allowing future work that passes the above litmus test. I'm  
hoping that the P2PRG can be used as a vessel for discussing related  
ideas that aren't quite ready for an IETF WG, but that would feed into  
the IETF effort once they're cooked.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Jul 2008 10:55:33 +0100

> "which peers would my ISP prefer I communicated with?"

Having had more coffe, I now remember that I believed that the cost  
information proposal also had reasonable answers.

Lars

---

From: Vijay Gurbani <[email-masked]>
Date: Wed, 30 Jul 2008 05:09:53 -0500

Lars Eggert wrote:
> whether we can answer these questions for each piece of information that 
> ALTO could carry:

Lars: Thanks for your clarification.  The first and last bullet
items below are okay -- the last one can conceivably be answered by
Henning's presentation.  However, the second one confuses me.
More inline.

>        *and* for the apps to use it?

In the list discussions, you have made a case that acquiring information
that changes on microseconds level is probably not a good thing.  So
let's consider acquiring a somewhat static information, like topology.

Are you saying that ALTO should specify a rough sketch of how an ALTO
box would obtain topological information?  So far we have assumed -- and
I believe that this is a good assumption -- that this sort of
"provisioning" happens behind the scenes and ALTO does not worry about
how the data got there.  ISPs will use whatever means they have for
populating a topological map, and independent third party ALTO services
will use Ono, Vivaldi, et al. to acquire such information (as a side
effect creating an innovation loop to do this better.)  But a hallmark
of all this is that ALTO simply queries and receives an answer.  How
that answer was derived is intentionally left out of scope.  Do you
agree with this?  If not, then will we be in the position of
*standardizing* the many ways topological maps must be derived?

I don't believe we want to go there, do we?  Some clarification would
be extremely helpful to Enrico and me as we digest the discussions to
create a new charter.

Thanks,

- vijay

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Jul 2008 11:30:15 +0100

Hi,

> let's consider acquiring a somewhat static information, like topology.

Right. I didn't mention this in my earlier email, but IMO frequently  
changing performance-related information should be out-of-scope for  
ALTO.

Topology-related information is fine, as you say. Or other kinds of  
information that has similar characteristics, such as about costs.

> how the data got there.

That's a good question - I was unclear. Let me try to expand on this.

I would *not* want an ALTO WG to produce documents that specify how an  
ALTO box gets or maintains the information it makes available.

But when we're talking about what kinds of information ALTO can be  
reasonably expected to be a query/response protocol for, I believe it  
is important to have an argument on how an ALTO box can be expected to  
actually have this information. In other words: designing an ALTO  
query/response protocol with support for queries about a particular  
kind of information that we have no idea about how an ALTO box would  
have it or get it is pointless.

>  ISPs will use whatever means they have for
> effect creating an innovation loop to do this better.)

Agreed.

>  But a hallmark
> agree with this?

Agreed.

As I said above, my point is that I wouldn't want to complicate the  
design of this protocol by needing to cater for queries for  
information that (1) apps can easily get in other ways, (2) we don't  
know how an ALTO box would get or maintain it and (3) where there is  
no benefit to the app and the owner of the ALTO box for using it.

>  If not, then will we be in the position of
> I don't believe we want to go there, do we?

I agree that we don't.

> Some clarification would

I hope I'm being more clear? (My caffein level is low.)

Lars

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 30 Jul 2008 12:26:39 +0100

Lars Eggert wrote:
> I would *not* want an ALTO WG to produce documents that specify how
> an ALTO box gets or maintains the information it makes available.
> 
> is important to have an argument on how an ALTO box can be expected
> to actually have this information. In other words: designing an ALTO 

Well, showing how an ALTO service could acquire topology information is
what the survey work (both the draft and the presentation) was meant to.
Are you suggesting to mention it in the charter, to address it in a
different way, or just to stress it more?

-- 
Ciao,
Enrico

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Jul 2008 12:39:40 +0100

> what the survey work (both the draft and the presentation) was meant  

My take-away from that part of the BOF was that there are many, many  
ideas for what kinds of topology-related (and other) information ALTO  
could provide, as demonstrated by the survey of existing (research)  
work. I didn't get a clear picture about which exact pieces of  
information we're expecting an IETF effort to standardize a query  
protocol for.

My comment is that I question whether if it useful to design ALTO to  
query for information that (1) is readily available to an application  
by other means, (2) we don't know where it would come from or what it  
would be good for, and (3) that doesn't have the correct incentives  
associated with it such that there was a benefit to providing and  
using it.

> different way, or just to stress it more?

I'd like the charter to explicitly list exactly which pieces of  
information ALTO will be a query protocol for, at least initially.  
("Topology-related information" is very vague.) For each of those  
pieces, I'd like to see the answers to the three "litmus test"  
questions from my earlier email (not in the charter, in an email or  
such.)

Lars

---

From: Philip Levis <[email-masked]>
Date: Wed, 30 Jul 2008 14:00:58 +0100

> information that has similar characteristics, such as about costs.

I think there are some misconceptions here about the intended scope of  
an Oracle's role. I'd argue -- and this agrees with what was in the  
presentation -- that the Oracle should not communicate complex  
information. The request is a list of resources (e.g., peers) and the  
response is a list of resources that is a subset of the request,  
perhaps ordered differently. There's a reason why such a simple  
interface is desirable: it's what a client might actually use.

As others have pointed out, p2p clients today continuously monitor the  
runtime performance of a subset of available peers. Distribution  
systems like bittorrent choke based on throughput, while lookup  
systems like Chord or other DHTs typically use latency. Clients use  
this runtime information to choose which of their set of potential  
peers they actively use.

A client cannot monitor the runtime performance of communication with  
10,000 other clients. So while run-time monitoring is necessary for  
good performance, clients greatly benefit from some guidance or  
recommendation on which peers to monitor. The problem with having a  
set of 100 randomly chosen peers is even probing all of them to find  
which 5-6 are 50-300% better than the others can be very expensive. So  
rather than give a client a set of random peers, an entity in the  
network can give the client a set of peers which, for whatever reason,  
are far to the right on the desired performance distribution. Or, give  
recommendations on which might be better than others.

Numerous studies have shown that, in the wild on real p2p applications  
today, information such as a rough sense of the network topology can  
allow a node in the network to give a client a very good set of peers  
that lead to significant performance gains. The problem is that  
collecting all of this information is expensive and requires a lot of  
effort. You don't want to have every client trying to generate an AS  
map. So instead you have some set of nodes that compute this topology  
information (iPlane is one example), and can then answer queries about  
peers using it.

The intention isn't that a client asks an Oracle for some tiny set of  
peers to use. Rather, a client can give an Oracle a set of peers, and  
the Oracle gives rough recommendations on which peers might be good.  
The client of course then has to monitor these at runtime. It might be  
that the best 4 peers in terms of network proximity are heavily  
loaded, so the client wants to use the next 4 closest instead.

There's a difference in time scale. You can't expect an Oracle to be  
able to measure performance as quickly or accurately as the client  
itself can, nor can you expect a client to spend the effort and time  
to generate the same long-term information the Oracle can.

Phil

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 30 Jul 2008 09:32:51 -0400

I think there are two useful queries, with the same input ("IP address  
P"):

(1) relative ordering of a set of an IP addresses; the ordering is  
expected to be correct in some average sense, similar to one would  
order Rome > Dublin > Reykjavik in terms of average temperature. This  
doesn't mean that on any given day Dublin is colder than Rome, just  
that this is likely. This my short version of the description below.

(2) Returning topology-related information for one or more IP  
addresses. This could be either equalities ("X1 is in the same AS as  
X2") or absolute values ("X1 is in AS 16"). The type of information we  
know how to produce, but have trouble obtaining in non-kludgey  
fashions today, include AS number, provider name, continent (or  
country), subnet. More sophisticated versions would include some  
notion of network distance, in some network coordinate system. A low- 
hanging fruit is to simply return the three or four coarse topology  
metrics and then add more as experience increases.

A query unifying the above would include the list X1, ..,, Xn, and  
return an ordered list, with the coarse topology information above.

Henning

>
> I think there are some misconceptions here about the intended scope  
> of an Oracle's role. I'd argue -- and this agrees with what was in  
> the presentation -- that the Oracle should not communicate complex  
> information. The request is a list of resources (e.g., peers) and  
> the response is a list of resources that is a subset of the request,  
> As others have pointed out, p2p clients today continuously monitor  
> the runtime performance of a subset of available peers. Distribution  
> A client cannot monitor the runtime performance of communication  
> with 10,000 other clients. So while run-time monitoring is necessary  
> for good performance, clients greatly benefit from some guidance or  
> which 5-6 are 50-300% better than the others can be very expensive.  
> So rather than give a client a set of random peers, an entity in the  
> network can give the client a set of peers which, for whatever  
> reason, are far to the right on the desired performance  
> distribution. Or, give recommendations on which might be better than  
> others.
>
> Numerous studies have shown that, in the wild on real p2p  
> applications today, information such as a rough sense of the network  
> topology can allow a node in the network to give a client a very  
> good set of peers that lead to significant performance gains. The  
> problem is that collecting all of this information is expensive and  
> requires a lot of effort. You don't want to have every client trying  
> to generate an AS map. So instead you have some set of nodes that  
> compute this topology information (iPlane is one example), and can  
> then answer queries about peers using it.
>
> The intention isn't that a client asks an Oracle for some tiny set  
> of peers to use. Rather, a client can give an Oracle a set of peers,  
> and the Oracle gives rough recommendations on which peers might be  
> good. The client of course then has to monitor these at runtime. It  
> might be that the best 4 peers in terms of network proximity are  
> heavily loaded, so the client wants to use the next 4 closest instead.
>

---

From: Philip Levis <[email-masked]>
Date: Wed, 30 Jul 2008 14:39:21 +0100

On Jul 30, 2008, at 2:32 PM, Henning Schulzrinne wrote:

>
>>>
>>>
>
> I think there are two useful queries, with the same input ("IP  
> address P"):
>
> order Rome > Dublin > Reykjavik in terms of average temperature.  
> This doesn't mean that on any given day Dublin is colder than Rome,  
> just that this is likely. This my short version of the description  
> below.

> X2") or absolute values ("X1 is in AS 16"). The type of information  
> we know how to produce, but have trouble obtaining in non-kludgey  

Why do you think an end-client wants/needs this information? I'm  
skeptical on depending on clients to take actions that benefit someone  
else (e.g., ISP) but harm them. The reason why the ordered list is so  
promising is that it turns out often the two optimization problems  
lead to very similar solutions.

At the very least, I'd argue separating (1) and (2) in terms of  
specification. (1) is so simple that it would be easy to nail it down,  
while (2) would require a bit more work.

Phil

---

From: Yu-Shun Wang <[email-masked]>
Date: Wed, 30 Jul 2008 06:51:31 -0700

Hi,

Comments inline.

Thanks,
yushun

> interface is desirable: it's what a client might actually use.

While simplicity is good in general, if the protocol is going to be
more generic than just for P2P, some indication of what criteria
is used to determine the list need to be provided. Actually, one
could argue even for P2P apps, there will be need for different
criteria. And that could potentially be an extensible option in
the protocol. But for each type of criteria, I agree that we don't
want to encode complex information.

> this runtime information to choose which of their set of potential

So there is potential need for different types of criteria.

> recommendations on which might be better than others.

This is arguing for the Oracle approach as oppose to dynamic
measurements done on each client. I agree there's a scalability
issue for the latter, but also want to point out that the Oracle
may not necessarily have (provisioned or pre-computed) all the
info on the potentially random list of nodes in the queries.
It all depends on the type of criteria that is used for the
queries/selection.

> loaded, so the client wants to use the next 4 closest instead.

Not that I disagree with the rationale or example, but it actually
sorts the list based on first locality then load. I guess my question
is what kind of semantics are we going to impose on the queries and
answers? I haven't seen it clearly stated yet.

> to generate the same long-term information the Oracle can.

Agreed. That is also why Lars wants to take the performance part out
of the charter (if it is on the table).
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 30 Jul 2008 09:59:19 -0400

> skeptical on depending on clients to take actions that benefit  
> someone else (e.g., ISP) but harm them. The reason why the ordered  
> list is so promising is that it turns out often the two optimization  
> problems lead to very similar solutions.
>

If it turns out that for a particular client (P2P or otherwise), it  
finds that this information correlates well with good performance, the  
client has an incentive to use it. This makes it easy to develop  
client/application-specific algorithms that rely on common  
information, rather than having each client spend a lot of kludgey  
effort (such as querying looking glass sites) to get at the data.

There seems to be significant published evidence that these metrics do  
correlate, on average, with improved performance, even if they  
occasionally miss the boat. It's the averages we care about, as long  
as the outliers aren't ridiculously bad and can be detected at run time.

> specification. (1) is so simple that it would be easy to nail it  
> down, while (2) would require a bit more work.

Depends on the level of detail reported. The items I mentioned seem  
trivial and extending the list later seems easy.

---

From: "Ulaş C. Kozat" <[email-masked]>
Date: Wed, 30 Jul 2008 08:43:34 -0700

My understanding of the problem after reading the sequence of e-mails is a
little bit confused. But I try to summarize my understanding of the ongoing
discussion (mostly I express them as questions):

Goal: To develop an "Oracle" architecture to guide peer selection process to
achieve some Macro performance and/or economical gains.
Question 1: Could such an Oracle system be useful to achieve these Macro
gains? It is useful iff P2P App cannot do it on its own in a reasonable time
and overhead while Oracle system can.
Question 2: Often P2P objectives (in terms of the optimization problem and
constraints) differ from one P2P system to another. Can different P2P Apps
communicate what they need to attain these objectives to the Oracle in some
Macro level and can Oracle make such an assessment  with the high level
topology, traffic load, etc. information?

Remark 1: If the answer to Question 1 is "no Oracle cannot be useful", I
think the argument that P2P anyways can fallback to its own selection
process is not convincing. The answer to Question 1 should be "Yes, the
Oracle system is mostly useful for an important set of P2P apps under at
least one interesting type of IP network  (e.g., 4G cellular)".

Remark 2: Some argue that there are enough research and experimental results
that hint that the answer to Question 1 is yes. Some argue they are
fictitious or insufficient or they do not use smart enough P2P Apps. I think
the research and experimental results should be classified in terms of
network assumptions, P2P objectives, and Query-Response types first. For
some assumptions, for some objectives, and for some query-response types, in
my opinion, there is enough evidence that Oracle works. But I am not sure
whether "smarter" P2P Apps themselves can do it in a reasonable time and
overhead under the considered set-up.

Remark3: Again my personal opinion is that if what P2P app wishes to achieve
is not well communicated with the Oracle system or what the Oracle system
returns back to the P2P App is not well specified apriori, the odds are it
won't be successful. Any chartering should seriously tackle down this issue.

Ulas

On Wed, Jul 30, 2008 at 6:59 AM, Henning Schulzrinne <[email-masked]>wrote:

>
>> Why do you think an end-client wants/needs this information? I'm skeptical
>> on depending on clients to take actions that benefit someone else (e.g.,
>> ISP) but harm them. The reason why the ordered list is so promising is that
>> it turns out often the two optimization problems lead to very similar
>> solutions.
>>
>>
> If it turns out that for a particular client (P2P or otherwise), it finds
> that this information correlates well with good performance, the client has
> an incentive to use it. This makes it easy to develop
> client/application-specific algorithms that rely on common information,
> rather than having each client spend a lot of kludgey effort (such as
> querying looking glass sites) to get at the data.
>
> correlate, on average, with improved performance, even if they occasionally
> miss the boat. It's the averages we care about, as long as the outliers
> aren't ridiculously bad and can be detected at run time.
>
>
>> specification. (1) is so simple that it would be easy to nail it down, while
>> (2) would require a bit more work.
>>
>
> Depends on the level of detail reported. The items I mentioned seem trivial
> and extending the list later seems easy.
>
>
>
>>
>> Phil
>>
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Jul 2008 16:58:37 +0100

Hi,

(1) is basically a relative query (order something provided by the  
querier based on who/where he is) while (2) is for absolute  
information. Both query types make sense to me.

But what query types make sense is orthogonal to which information or  
measure is being queried, which is what my concern was about.

> just that this is likely. This my short version of the description  

By what measure or measures will this ordering happen? For each of  
these kinds of measure or information, what's the "litmus test"  
argument?

> country), subnet.

I agree that these kinds of information we know how to provide. But at  
least some of those are also easily obtainable by an application. BBC  
iPlayer and similar apps in other countries seem to have little  
problems determining where my IP address is from. Where is the benefit  
of getting this information through an ALTO box?

> More sophisticated versions would include some notion of network  
> distance, in some network coordinate system. A low-hanging fruit is  
> to simply return the three or four coarse topology metrics and then  
> add more as experience increases.

With my researcher hat on, I agree, but with my IETF hat on, I'd argue  
that the P2PRG seems like the correct home for such proposals at this  
time.

Lars

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 30 Jul 2008 12:53:14 -0400

> these kinds of measure or information, what's the "litmus test"  

I can see several approaches:

- "Opaque oracle": The oracle won't tell you how it arrived at the  
ordering - you just have to trust the result. After all, the  
weatherman on TV also doesn't tell you why he thinks it will rain  
tomorrow and Delphi never revealed its reasoning, either. Oracles that  
help end users, prosper. This works reasonably well if there is a  
single ordering that works well for a variety of applications.

- "Semi-opaque oracle": The querier says "low latency" or "high  
throughput". The oracle consults its backend (such as the ones  
described during the BOF) and returns an appropriate (partial) ordering.

- Transparent: Querier provides some objective function.

I suspect that the 2nd version is reasonable, in that it shields the  
client from the details of the backend database.

>> addresses. This could be either equalities ("X1 is in the same AS  
>> as X2") or absolute values ("X1 is in AS 16"). The type of  
>> information we know how to produce, but have trouble obtaining in  
>> non-kludgey fashions today, include AS number, provider name,  
>> continent (or country), subnet.
>
> I agree that these kinds of information we know how to provide. But  
> at least some of those are also easily obtainable by an application.  
> BBC iPlayer and similar apps in other countries seem to have little  
> problems determining where my IP address is from. Where is the  
> benefit of getting this information through an ALTO box?

None of these mechanisms are standardized, as far as I know. How do  
you currently determine the simple items I mentioned before?

For example, there are a number of IP-to-geo mapping services  
(MaxMind, Quova, etc.), but each uses a different "protocol". Thus, an  
application has to be tied to a specific provider, which seems far  
from ideal. With the same argument, we could get rid of HTTP and DNS...

> With my researcher hat on, I agree, but with my IETF hat on, I'd  
> argue that the P2PRG seems like the correct home for such proposals  
> at this time.

I don't see returning AS numbers and the other information as  
"research", even if the longer-term metrics may be.

The alternative to ALTO is not "research", but lots of proprietary  
alternatives that don't feel encumbered by the same level of doubts.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Jul 2008 17:55:50 +0100

> argue that the P2PRG seems like the correct home for such proposals  

And because I got asked: I was referring to the "sophisticated  
versions" in Henning's email, *not* the entire ALTO effort. As I said  
before, I do believe we have identified some pieces that seem ready to  
charter.

Lars

---

From: "Y. R. Yang" <[email-masked]>
Date: Wed, 30 Jul 2008 13:21:17 -0400 (EDT)

On Wed, 30 Jul 2008, 12:53pm -0400, Henning Schulzrinne wrote:

> > >(1) relative ordering of a set of an IP addresses; the ordering is expected
> > >to be correct in some average sense, similar to one would order Rome >
> > >Dublin > Reykjavik in terms of average temperature. This doesn't mean that
> > >on any given day Dublin is colder than Rome, just that this is likely. This
> > >my short version of the description below.
> >
> >By what measure or measures will this ordering happen? For each of these
> >kinds of measure or information, what's the "litmus test" argument?
> >
> 
> - "Opaque oracle": The oracle won't tell you how it arrived at the ordering -
> you just have to trust the result. After all, the weatherman on TV also
> doesn't tell you why he thinks it will rain tomorrow and Delphi never revealed
> its reasoning, either. Oracles that help end users, prosper. This works
> reasonably well if there is a single ordering that works well for a variety of
> applications.
> 
> - "Semi-opaque oracle": The querier says "low latency" or "high throughput".
> The oracle consults its backend (such as the ones described during the BOF)
> and returns an appropriate (partial) ordering.
> 
> I suspect that the 2nd version is reasonable, in that it shields the client
> from the details of the backend database.
 
By Henning's classification, the current P4P field test provides an 
example metric of the first category: the "opaque" p4p distance (or 
pdistance or vcost). In the most "sophisticated" version, the pdistances 
are determined by the shadow variables of a primal-dual decomposition to 
conduct optimal ISP traffic engineering. These terms sound scary, but if 
you ask economists on primal-dual decomposition and shadow prices to 
explain market economies, they typically can give you a simple 
explanatinon. Of course, this pdistance may also reflect in a sense the 
relatvely static CAPEX or OPEX of an ISP network, if an ISP chooses so. I 
guess this why it should be considered opaque. I do not see this 
"opaqueness" as bad. Henning gave good examples. When I buy something in a 
market, I do not ask exactly how the prices are derived.
 
> > >(2) Returning topology-related information for one or more IP addresses.
> > >This could be either equalities ("X1 is in the same AS as X2") or absolute
> > >values ("X1 is in AS 16"). The type of information we know how to produce,
> > >but have trouble obtaining in non-kludgey fashions today, include AS
> > >number, provider name, continent (or country), subnet.
> >
> None of these mechanisms are standardized, as far as I know. How do you
> currently determine the simple items I mentioned before?
> 
> For example, there are a number of IP-to-geo mapping services (MaxMind, Quova,
> etc.), but each uses a different "protocol". Thus, an application has to be
> tied to a specific provider, which seems far from ideal. With the same
> argument, we could get rid of HTTP and DNS...
> 
> 
> >
> >
> > >More sophisticated versions would include some notion of network distance,
> > >in some network coordinate system. A low-hanging fruit is to simply return
> > >the three or four coarse topology metrics and then add more as experience
> > >increases.
> >
> >
> >With my researcher hat on, I agree, but with my IETF hat on, I'd argue that
> >the P2PRG seems like the correct home for such proposals at this time.
> 
> I don't see returning AS numbers and the other information as "research", even
> if the longer-term metrics may be.
>

---

From: "Ulaş C. Kozat" <[email-masked]>
Date: Wed, 30 Jul 2008 10:38:29 -0700

My comment is at the bottom.

Ulas

> ordering -
> throughput".
> client
It is not maybe essential to know how the price is computed, but it is
critical to know
if that pricing is done with respect to P2P App's expectation. If I reuse
the analogy above,
it is a waste of time to go to an expensive store if there is not any chance
of buying anything.
I better know a-priori if my constraints are in line with the pricing.
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi