Subject: Re: [p2pi] why I didn't hum yes (yet)

From: "Satish Raghunath" <[email-masked]>
Date: Wed, 30 Jul 2008 13:21:46 -0700

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

A few observations regarding P2P expectations are useful here.

a) Henning and Richard's suggestion of an abstract goal for the
relative order (e.g. low latency) conveys these expectations. From the
application standpoint, it is now relieved of topology or network
details in order to answer "what does it mean in networking terms if I
want low latency?".

b) The question of trusting the "price"/"ordering" provided by the
Oracle is somewhat easier to answer. Any computation that does not
reasonably achieve both the provider and application's goals will
naturally lose its popularity. The applications are free to ignore the
Oracle's advice when they find out that results are not up to
expectations. That means if there is a big enough constituency that
finds the Oracle useful, it has reason to exist.

In any case a standard query-response medium allows the community to
discover and evolve better ordering/pricing/info-dissemination
methods.

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

---

From: Laird Popkin <[email-masked]>
Date: Thu, 31 Jul 2008 08:28:02 -0400 (EDT)

I'd like to expand on Satish' comments:

- The ALTO server's guidance must be viewed as advisory by the p2p applications, will will in practice use it as an additional information source used in addition to whatever other strategies the p2p application uses. So if the guidance is bad, the p2p network won't use it. That is, even if the p2p network doesn't decide not to trust a particular ALTO source, the existing mechanisms for p2p transit optimization will apply, minimizing the "pain" caused by bad guidance.

- Random peer selection is so inefficient, that any degree of guidance is likely to be quite helpful, which is of (IMO) greater benefit than the relatively subtle differences between guidance strategies. That is, if I connect to a 'low latency' peer or a 'bulk data' peer, while one or the other would be better for a particular use, either will be better than a random peer somewhere on the planet. So while I think that there's a lot of good optimization that can be done by making the most appropriate recommendation, I believe that having any recommendation at all is so much of a benefit that I'm happy solving the simplest case first (i.e. let the ALTO server define "best" any way that it likes) and then we can tackle the complex case (i.e. negotiating priorities and rankings between the ALTO client and server). As long as the protocol is extensible (which is a requirement), this can be addressed over time.

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

----- Original Message -----
From: "Satish Raghunath" <[email-masked]>
To: [email-masked]
Sent: Wednesday, July 30, 2008 4:21:46 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] why I didn't hum yes (yet)

Thanks,
Satish

---

From: Laird Popkin <[email-masked]>
Date: Thu, 31 Jul 2008 09:01:30 -0400 (EDT)

One thing that limits the harm caused by bad guidance is that p2p networks do not use just the nodes provided by ALTO, but also establish random peer connections using existing mechanisms (e.g. peer exchange). For example, in the P4P field tests, we used 80% P4P guidance and 20% random peers, and peers also find more 'random' peers over time (e.g. peer exchange). This was done so that the p2p network is robustly connected between ISPs (for example), while using 100% P4P guidance could potentially lead to isolated clusters of peers in each ISP, which would be harmful to the network.

The random peer connections interact with the p2p networks' ongoing optimization of peer transfers to take advantage of 'good' guidance, and to limit the harm caused by 'bad' guidance.

For example, let's consider the ALTO recommendations as being 'great'. In this case a peer might 40 great peer recommendations and 10 random ones. The peer will immediately start using the 'great' peers and download only minimally from the 'random' peers.

Now let's consider the ALTO recommendations as being 'bad', where they're worse than random peers. In this case a peer might get 40 'bad' peer recommendations and 10 random ones. The peer might waste time trying the 'bad' peer recommendations, but then optimizes to use the faster 'random' peers. So while bad guidance slows down the initial speed ramp a bit, the impact is limited.

In P4P testing, we saw that good guidance could generate increases of download speed of 3x or better, and 10x in some cases, and that bad guidance could generate slowdowns of perhaps 20%.

----- Original Message -----
From: "Henning Schulzrinne" <[email-masked]>
To: "Philip Levis" <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, July 30, 2008 9:59:19 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] why I didn't hum yes (yet)

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

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.

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

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

> Phil