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

From: Reinaldo Penno <[email-masked]>
Date: Fri, 01 Aug 2008 03:53:49 -0700

Hello Laird,

Regarding your first point. If you have users 1..N downloading from the
Internet which increases inter-domain and downstream links, if they start
downloading from their neighbors that by definition increases uplink
congestion doesn't it?

The above is not true unless you assume that P2P users upload a certain
amount of bandwidth irrespective of the peer. But (and you probably have
more data on this) although you might localize downstream, and if upstream
is not localized (or on the other hand allows for more bandwidth), you
definitely get more upstream, right? The premise is that you are telling
peer A or others peers in its local network that peer A would not have
chosen otherwise. 

Finally, I would like to understand if any of the P4P tests have been down
with PEX and DHT fully enabled? I would like if possible to understand the
dynamics of ALTO suggesting a few peers whereas a peer learn 3000 other
peers through other means you cannot control.

Some data I've seen shows a peer can easily learn all peers in a huge swarm
much faster than we could influence its behavior.

Anyway, although ALTO can produce a protocol the dynamics of such system
should be captured.

Thanks,

Reinaldo

On 8/1/08 1:42 AM, "Laird Popkin" <[email-masked]> wrote:

> 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,
> 
> 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
> _______________________________________________
> 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: Laird Popkin <[email-masked]>
Date: Fri, 1 Aug 2008 08:22:44 -0400

> peer A or others peers in its local network that peer A would not have

In the most recent P4P test we preferentially connected peers within  
the same ISP, with the result that while there was increased demand  
for uplink to send data to same-ISP peers, there was decreased demand  
for uplink to send data to other-ISP peers.

Note that localizing p2p peer connections localizes both uplink and  
downlink transit, since p2p connections are bi-directional. For  
example, peers connect out to other peers in order to send them data,  
not just to receive data from them.

> peers through other means you cannot control.

This is a very good question; in the tests we used P4P guidance in  
combination with 'random' peers. Specifically, in the tests we used  
P4P iTracker (AKA ALTO server) guidance to give peers 80% of their  
peer assignments, and gave 20% random peers so that the swarm wasn't  
completely segmented. In addition, we perform peer exchange, so over  
time peers learn about the entire swarm. This did not appear to reduce  
the benefit of traffic localization, because our software (like many  
others) optimizes to use the fastest data sources, so if the local  
data sources are fastest, they continue to be used, and remote data  
sources are relatively unused. And if the remote data sources are  
faster than the local ones, we _want_ to use them, for improved  
performance, even at the cost of some increased transit use.

> much faster than we could influence its behavior.

Yes, peers can learn the addresses of the other peers fairly quickly.  
The part that takes time is in exchanging data with each peer and  
measuring the throughput in order to determine which peers are  
fastest. It takes about 2 second per peer to do a quick data exchange  
to measure throughput, so a swarm of 1,000 peers would take perhaps  
2,000 seconds to profile all peers in the swarm. Of course, this is an  
incremental process, so in 1,000 seconds half of the swarm would have  
been profiled, etc.