Subject: Re: [p2pi] p2p localization and transit vs. local traffic

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

Ivica,

At 23:08 31/07/2008, Ivica Rimac wrote:
>Bob,
>
>but isn't a P2P content network's self-scaling property based on the 
>assumption that each peer sources as much data as it consumes (at 
>least in average)? I.e., the total amount of data sourced from peers 
>sholdn't change

Agreed, but...

>and even with a pure random peer selection approach (a la BT) peers 
>have a chance of being selected by other (local or remote) peers as sources.

I'm not saying random is good. I'm saying localisation is not good. 
And there's a better way...

>I do not see transit reduction generally implying an increase in 
>local network traffic other then when the P2P network is running in 
>surplus mode.

Eh? If a sink moves its traffic source from a remote peer to a local 
one, that's more traffic on the local upstream and less on the remote 
upstream and less on the interconnect.

I'm saying the best allocation is congestion minimisation. Which is 
significantly different from topological localisation.

Some networks have less upstream congestion than others as a result 
of their design constraints (e.g. DSL vs cable). So using a certain 
amount of interconnect between the two types is more optimal than 
localising within one type. But /only/ until congestion 'balances 
out' to minimum everywhere.

A good modern congestion control is good at congestion minimisation 
(but note that TCP has the 1/RTT artefact that skews matters unlike 
more modern controls - see my slides).

So if you want to judge whether an oracle is performing well,
- don't judge how well it localises
- judge whether it bootstraps connections in the same pattern that 
BitTorrent DNA would evolve to - given enough time.

This also says the P2P network has the best info to help the oracle, 
not the individual ISPs which only have topology info and partial 
congestion info.

Bob

>-ivica
>
>
>>> >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".
>
>--
>   Ivica Rimac                        Bell Labs / Alcatel-Lucent
>   Email: [email-masked]           791 Holmdel-Keyport Road
>   Phone: +1-732-888-7205                 Holmdel, NJ 07733, USA
>
>

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

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

---

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

Field test data does not support the assertion that "If a sink moves its traffic source from a remote peer to a local one, that's more traffic on the local upstream and less on the remote 
upstream and less on the interconnect." I think that you're thinking only about internal data transfer, and forgetting that the users are currently uploading not only to other customers of the same ISP (2% of the time, on average), but also (98% of the time, on average) to users on the rest of the internet. While there's a alrge increase in local upstream uploading to other customers of the same ISP, there's a cooresponding drop in local upstream uploading to the general internet. So far in field testing the two effects balance each other out, so total uplink consumption doesn't change much.

Regarding "This also says the P2P network has the best info to help the oracle, 
not the individual ISPs which only have topology info and partial 
congestion info." I would modify this to say that neither the p2p network nor the ISP have sufficient information in isolation to make the best peer assignment selections. So (IMO, of course) the ISP should provide information to the p2p network that, in combination with what the p2p network knows, allows it to make better peer assignment selections. Specifically, the p2p network knows a lot about peer network profile (e.g. firewalled, current utilization) and the ISP knows about network topology, and by working together the two can make much better choices than either by themselves.

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

----- Original Message -----
From: "Bob Briscoe" <[email-masked]>
To: "Ivica Rimac" <[email-masked]>
Cc: [email-masked]
Sent: 01 August 2008 01:31:59 o'clock (GMT) Europe/London
Subject: Re: [p2pi] p2p localization and transit vs. local traffic

Ivica,

Agreed, but...

Bob

---

From: Ivica Rimac <[email-masked]>
Date: Thu, 31 Jul 2008 18:08:30 -0400

Bob,

but isn't a P2P content network's self-scaling property based on the 
assumption that each peer sources as much data as it consumes (at least 
in average)? I.e., the total amount of data sourced from peers sholdn't 
change and even with a pure random peer selection approach (a la BT) 
peers have a chance of being selected by other (local or remote) peers 
as sources.
I do not see transit reduction generally implying an increase in local 
network traffic other then when the P2P network is running in surplus mode.

-ivica

>> >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)...
> 
> * 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?
> 
> already has shared congestion upstream (a cable network does), that's 
> making it _worse_ both for local p2p & non-p2p users.
> 
>