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

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

I believe that the question should not be whether any P2P app cannot achieve the  optimizations  without a standard protocol, because many p2p networks implement some sort of optimization related to localization of data transfer, often using something oracle-like, but whether it is valuable to have a common protocol for communication between network operators and applications. 

Addressing remark 1: localizing network traffic (based on the p4p field tests, which used ISP network maps and an "oracle") shows a strong benefit in transit reduction and in performance improvement, for networks that are DSL, Cable or FTTH. 

Addressing remark 2: the guidance provided by an ALTO server could vary based on a wide range of metadata. For example, different p2p networks might receive different guidance. Or guidance could vary based on class of content (e.g. paid commercial content vs. consumer generated content). Rather than try to incorporate a wide range of specific metadata fields into the ALTO protocol, I believe that for now it would be better to simply make sure that ALTO requests are extensible so that vendors and providers can implement whatever metadata that they require, and over time useful metadata fields can be standardized. 

Addressing remark 3: I believe that it may not be possible to define "best", and we should leave that definition open to ALTO implementers, and to  extensions  of the protocol. For example, a p2p network could the same protocol to deliver real-time video streams, and background downloads., so to differentiate between the two the application could tell the ALTO server the use case, and the ALTO server could send appropriate guidance. 

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

----- Original Message ----- 
From: "Ulaş C. Kozat" <[email-masked]> 
To: "Henning Schulzrinne" <[email-masked]> 
Cc: [email-masked] 
Sent: Wednesday, July 30, 2008 11:43:34 AM (GMT-0500) America/New_York 
Subject: Re: [p2pi] why I didn't hum yes (yet) 

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. 

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 

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

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

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

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 31 Jul 2008 18:54:06 +0100

Laird,

At 13:45 31/07/2008, Laird Popkin wrote:
>Addressing remark 1: localizing network traffic (based on the p4p 
>field tests, which used ISP network maps and an "oracle") shows a 
>strong benefit in transit reduction and in performance improvement, 
>for networks that are DSL, Cable or FTTH.

I think my rather important previous point got missed (sorry my mail 
had a lot of points)...

Neither of these metrics for 'better' impresses me much at all.

* If performance of p2p is better, and if there is shared congestion 
with other non-p2p users on the same local network, this means the 
performance of others will most likely be worse. Overall, is this 
better or worse?

* If there's transit reduction, equivalent traffic will instead be 
being uploaded from the local network. Again, if the local network 
already has shared congestion upstream (a cable network does), that's 
making it _worse_ both for local p2p & non-p2p users.

It costs more (bit for bit) to upgrade access and backhaul than it 
does to upgrade interconnect (there's a considerable economy of 
scale). If someone from a cablecco has told you it's most important 
to reduce transit costs, you'll find they did NOT mean "and at the 
same time please introduce higher backhaul and access costs instead".

See the picture I posted yesterday to this list: 
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0807ietf/0807alto-briscoe.pdf>

The Internetwork is provided to be used. Let's not assume a 
DISINTERNET is 'better' without being clear what 'better' means.

I've seen no research that uses a full cost-benefit analysis. That's 
hard (e.g. what's the relative value of p2p bits versus non-p2p 
bits). But without such a study, unfortunately, what everyone is 
calling 'better' looks like 'worse' to me on second looks - at least 
for networks with a congested upstream.

On third looks (ie a full study) it might not be worse. But can 
people please enter this debate on the assumption that network 
economics is dangerous in the hands of amateurs (which includes the 
large majority of folks even in telcos/cablecos).

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 31 Jul 2008 14:57:08 -0700

I believe see your point. Even if we decouple the optimization part from the
protocol, we are still doing this work under the assumption that the
optimization will make everybody happy (based on some policy).

If it cannot be proved that the optimization work for P2P clients _and_
Service Provider on a cost-effective basis then the protocol work is moot.

I think a cost analysis of such optimizations from a Service Provider point
of view would be interesting.

Thanks,

Reinaldo

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 01 Aug 2008 01:14:01 +0100

Reinaldo,

There's no need to include the service provider's (ISP's) view.

I was merely proposing we should include the non-p2p users 
potentially impacted by the better performance of p2p.

People often talk about harm to 'the network', but the ISP isn't 
harmed. It's other user's traffic that is harmed. The ISP's aim is to 
try to ensure its customers as a whole get most out of the network - 
only in that sense is the ISP 'harmed' if they don't - because the 
ISP is then less competitive against another ISP that manages to 
achieve a better carve up.

Bob

At 22:57 31/07/2008, Reinaldo Penno wrote:
> <http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0807ietf/0807alto-briscoe.pd> 
> f>
> >

---

From: Philip Levis <[email-masked]>
Date: Fri, 1 Aug 2008 02:14:25 +0100

On Jul 31, 2008, at 6:54 PM, Bob Briscoe wrote:

> already has shared congestion upstream (a cable network does),  
> that's making it _worse_ both for local p2p & non-p2p users.
>
>
> See the picture I posted yesterday to this list: <http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0807ietf/0807alto-briscoe.pdf 
> >
>

Bob, I think you're getting lost in the weeds here.

The goal is to define a mechanism by which entities with a greater  
knowledge of the network can provide guidance to clients on whom those  
clients might want to communicate with.

This guidance could be based on localization, or it could be based on  
other properties which turn out to be better but we have not  
discovered yet. The interface proposed, (X,Y,Z) -> (Z), does not  
assume localization. Doing so would be folly, as it would preclude  
using the mechanism for applications which are better served by other  
selection policies.

That being said, the points in your slides are interesting. Do you  
have any real and repeatable experimental evidence that it's "worse?"  
I'll admit that none of the experimental studies cover every single  
edge case -- they would then be so voluminous as to be unreadable --  
but I'm tempted to trust experimental data collected from real  
networks over back-of-the-envelope calculations.

Phil

---

From: Laird Popkin <[email-masked]>
Date: Fri, 1 Aug 2008 04:31:55 -0400 (EDT)

To add a little field test data, so far we've not seen any cases where traffic localization increased "last mile" uplink consumption. When traffic isn't localized, an ISP's customers are uploading to the general internet. When traffic is localized, an ISP's customers upload about the same volume, but the destination of the upload shifts from external to internal destinations. This happens in part because the ISP's customers connect to each other, and in part because the external users connect to each other instead of connecting into the ISP. The result is that the consumption of the "last mile" doesn't change, but the consumption of internal and external links drops.

You're right that a cost analysis is complex, since it varies dramatically between ISPs (and is subject to debate within ISPs). That's why I'd rather talk about resource consumption (e.g. data volumes, link utilization).

----- Original Message -----
From: "Philip Levis" <[email-masked]>
To: "Bob Briscoe" <[email-masked]>
Cc: "Laird Popkin" <[email-masked]>, [email-masked]
Sent: 01 August 2008 02:14:25 o'clock (GMT) Europe/London
Subject: Re: [p2pi] why I didn't hum yes (yet)

Phil

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 1 Aug 2008 04:25:26 -0400

Bob,
 
I feel compelled to respond to some of your points.
 
At Comcast, we studied the P4P results from Verizon earlier this year, before we committed to a trial this summer. There were three items of interest from those results:

1.	
	Faster downloads for P2P users
2.	
	Reduced backbone transit traffic for the ISP
3.	
	* The same aggregate amount of uploading by ISP customers

We're not ready to reveal the results of our own recently-concluded P4P trial, but suffice it to say that we are seeing similar results. I suspect the reason behind point #3 is that P2P uploads within the ISP displace the P2P uploads outside the ISP. And the reason behind point #2 may be that there are fewer outside factors (e.g. multiple transit backbones) that could cause congestion.

We need to perform more analysis before we can conclude that ISP localization doesn't increase upstream traffic, but at least on average it does not increase upstream traffic. If it turns out that P4P localization is cost-neutral on an access basis, then that would be a critical item to retain for ALTO.

BTW, I agree with many of your other comments. For example, I agree that minimizing RTT for P2P connections isn't all that critical. For example, I've heard that clever P2P users are often motivated (where possible) to select peers in Japan and Korea, because higher upload throughput trumps RTT every time.

>It costs more (bit for bit) to upgrade access and backhaul than it does to upgrade interconnect (there's a considerable economy of scale). If someone from a cablecco has told you it's most important to reduce transit costs, you'll find they did NOT mean "and at the same time please introduce higher backhaul and access costs instead".
 
I've been talking to Laird, and I seem to be from a 'cableco', so maybe you're referring to me. (And maybe I'm one of the amateurs as well.) :^/
 
But I am pretty sure I have been consistent on this point, from the P2PI Workshop to the ALTO BOF to other private conversations -- our broadband access costs are much higher than our backbone / transit costs. As my boss would say, "backhoe costs don't follow Moore's Law". For Comcast, minimizing transit costs is nice but not the fundamental concern.
 
BTW, I have heard that for other ISPs, transit costs *are* a fundamental issue. And not just in the so-called "third world".
 
-- Rich

Laird,

Bob