Subject: Re: [p2pi] After-BoF charter

From: Bob Briscoe <[email-masked]>
Date: Thu, 04 Sep 2008 13:53:08 +0100

Phil,

[Sorry, I just realised I mistakenly dropped the p2pi list from this 
response originally sent 29 Aug - re-posting, for the record.]

Continuing after long intermission due to holiday season...

You are right, but the explanation you give below uses a model of how 
p2p networks work that is too restrictive to make it believable. 
Reciprocity requirements don't mean 2 peers have to upload & download 
from /each other/. However, you did help me realise I was wrong.

Here's why I was incorrect (it explains P4P's experimental results) 
using your local/distant identifiers. I was looking at it this way:

BEFORE (incorrect)
+--------------------+
|  .->               |         -.
| :  ________________|_    ____  :
| | /                | \  /    \ |
| ||                 |  ||      ||
| |V                 |  |V      |V
|                    |
| L1       L2        |  D2      D1
+--------------------+

AFTER (incorrect)
+--------------------+
|  .->               |         -.
| :  _____    _______|_________  :
| | /     \  /       |         \ |
| ||       ||        |          ||
| |V       |V        |          |V
|                    |
| L1       L2        |  D2      D1
+--------------------+

But I overlooked the fact that I can't just cut D2 out. D2 was 
involved because it wanted a download and therefore D2 has to find 
someone who wants its upload.  Similarly, L2 won't get involved 
unless it was downloading before. The 'minimum molecule' involved in 
a shift contains 4 nodes. I should have looked at it this way:

BEFORE (correct)
+--------------------+
|  .->               |         -.
| :         ___________________  :
| |  ______|___________        \ |
| | /      |  _________ \       ||
| ||       | /       | \ |      ||
| ||       ||        |  ||      ||
| |V       V|        |  V|      |V
|                    |
| L1       L2        |  D1      D2
+--------------------+

AFTER (correct)
+--------------------+
|  .->               |         -.
| :  _____    _________    ____  :
| | /     \  /       | \  /    \ |
| ||       ||        |  ||      ||
| ||       ||        |  ||      ||
| |V       |V        |  |V      |V
|                    |
| L1       L2        |  D1      D2
+--------------------+

For the charter discussions, this throws new light on whether ALTO 
servers will be used for more general localisation purposes. I 
believe we can make this (carefully worded) statement:

Localisation of file-sharing peers /only/ harms no-one if the app 
enforces upload-download reciprocity, at least approximately.

Any use of ALTO services by different apps needs to have its own 
incentive model to make it likely to be welcomed by all parties.

Specific nits inline...

At 23:54 12/08/2008, Philip Levis wrote:

>On Aug 8, 2008, at 5:40 PM, Bob Briscoe wrote:
>>
>>As I have to keep saying, and as Richard Woundy from ComCast has
>>agreed, excessive cross domain traffic is much less bad than
>>excessive local traffic.
>
>I'm not sure I understand this concern or argument. Let's examine two
>cases:
>
>   Case 1: Local peers L1 and L2 are both on the same local broadband
>network and are active peers of one another.
>   Case 2: Local peer L1 is actively peering with distant peer D1, and
>L2 is actively peering with distant peer D2.

We need more precision: I assume by 'actively peering' in case 2 you 
mean both uploading & downloading from each other.

These two cases aren't useful to compare because they compare 2D+2U 
with 4D+4U, where
D = downloads
U = uploads.

>The argument is that case 2 can be preferable to case 1 when local
>broadband access is the limiting resource. Or, in the even more
>extreme case, when L1 and L2 are on the same wireless AP, every packet
>occupies the link layer twice (e.g., L1->AP, AP->L2).
>
>Ultimately, if L1 and L2 are actively peering, they're going to be
>both sending and receiving data. Whether or not this data is to
>distant or local nodes doesn't matter: it's going to occupy the
>network either way. Consider the case where D1 and D2 are simple
>forwarders, such that
>
>L1 <-> D1 <-> D2 <-> L2
>
>so L1 and L2 are communicating with one another. All D1 and D2 will do
>is increase the RTT. Or is there an assumption that there will be a
>bottleneck elsewhere in the larger network so the overall throughput
>of local to distant nodes is lower than between local nodes?

Reciprocity requirements of p2p apps don't mean 2 peers have to 
upload & download from /each other/.

Bob

>Phil

____________________________________________________________________________
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: Stanislav Shalunov <[email-masked]>
Date: Thu, 4 Sep 2008 14:25:17 -0700

For clarity, in BitTorrent, the example of P2P system that people  
usually have in mind when talking about reciprocity, the tit-for-tat  
algorithm involves only pairs of peers trading with each other, not  
longer chains.

Longer chains can be formed out of bidirectional relationships, but  
aren't analyzed.

(It could have been designed to look at upload/download instead, but,  
because client software isn't trusted and collusion is trivial by  
starting sacrificial instances that *say* they downloaded from you,  
it's non-trivial.  The way this is handled by private trackers is by  
keeping track of people's long-term totals.  The metrics they use  
could be substantially improved, but they are what they are.)

This is all details.

The deal is simple: in a swarm, total upload = total download.  An ISP  
can't expect to put up an ALTO box and lower uploads by its  
customers.  The way to break through this, if desired, is by caching,  
where uploading is shifted to a cache not behind a home connection.

-- Stas

--
Stanislav Shalunov

---

From: Laird Popkin <[email-masked]>
Date: Thu, 4 Sep 2008 18:42:03 -0400 (EDT)

In any case, reciprocity is only approximate, so it shouldn't be assumed as a requirement for ALTO. It doesn't apply to most live streaming protocols, for example. And even in BitTorrent, tit-for-tat really only applies between downloaders - once there is a seed involved, the data flow is one-way (from the seed to the leech).

Sanislav is exactly right in terms of the global data flow - by definition, pure p2p has total upload = total download.

In practice, however, there is an inequality between peers and between ISPs, because uplink capacity is not equal. For example, because p2p networks optimize to use the fastest available data sources, higher speed consumer ISPs (e.g. FTTH) are generally net exporters of data, while lower speed consumer ISPs (e.g. DSL) are generally net importers of data. Localizing traffic within an ISP would tend to reduce this inequality.

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

----- Original Message -----
From: "Stanislav Shalunov" <[email-masked]>
To: "Bob Briscoe" <[email-masked]>
Cc: [email-masked]
Sent: Thursday, September 4, 2008 2:25:17 PM (GMT-0800) America/Los_Angeles
Subject: Re: [p2pi] After-BoF charter

This is all details.

-- Stas

--
Stanislav Shalunov