Subject: Re: [alto] [p2pi] Mythbustering P2P traffic localization

From: Laird Popkin <[email-masked]>
Date: Thu, 26 Feb 2009 11:46:18 -0500 (EST)

Nice write-up.

I would shorten the definition of 2.5 "Surplus Mode" to "The status of a swarm where the upload capacity exceeds the download demand". You could also call this "well seeded".

I would change 2.6's title to "Paid Transit" to be a bit more explicit about the distinction between it and peering ("direct connections").

In 4.1.1, I wouldn't conclude from one test that "the collected data also indicate that fine-grained localization is less effective in improving download performance compared to lower levels of localization", because additional "tuning" of the fine-grained guidance could well produce superior results to course grained guidance.

Also related to this, I would point out that it's important that applications not use network guidance as the sole determinant of p2p data exchange. This is important in order to prevent the p2p network from fragmenting (e.g. each ISP is an 'island' without inter-ISP connections) and to minimize the negative impact in some cases (e.g. all local users have very limited uplink capacity).

In 4.2, "imposing locality when only a small set of local peers are available" I would suggest that network guidance should never be used to exclude available peers, but simply to prioritize the order of connection/data exchange. If a swarm has only 10 peers, with 1 local, the p2p network should connect first to the local peer, but then proceed to connect to all available peers.

To elaborate on 5.1, what we observed is that while the total uplink utilization did not change, there was a significant reduction in the uplink data sent off-net, balanced by a matching increase in uplink data sent on-net. For example, Comcast customers served more data to each other, and less data to the rest of the internet.

Related to 6, note that guidance can be applied to inter-ISP connections, so that ISPs could use the guidance to shift traffic away from paid transit links towards peering links (for example). Because p2p traffic (between consumer ISPs) tends to be balanced (i.e. once peers connect, they ship data bi-directionally), this should help ISPs balance their peering links.

Related to 7, in the last P4P field test we had a wholesale provider and a retail ISP both participate, which raised the question of how the 'overlap' was addressed. We use the rule that the longest IP address prefix match determined the source of the guidance, which resulted in the users within the retail network to receive guidance from the retail ISP's iTracker, and the other users within the wholesale network receive guidance from the wholesale ISP's iTracker. We also demonstrated that the wholesale ISP's iTracker could internalize traffic within the wholesale network in a similar manner to retail ISPs. This was not analyzed from an economic perspective.

Also related to 7, if ISPs start providing guidance that manipulates p2p data flow in ways that significantly degrade application performance, it is likely that applications will either stop using the guidance or learn to do so selectively.

In 8, I agree that this is an area for continued research. While all of the research on this front has simulated restricted peer inter-connections based on locality, I would suggest that applications would not in practice use locality guidance to limit peer inter-connections - it is important that over time swarms are fully meshed in order to be resilient, which should limit the ability of "bad guidance" to damage the network. That is, while a peer might get "bad" peers first, it should over time discover the rest of the swarm, after which it should function normally (i.e. optimize to utilize the peers with the fastest observed throughput), with the only cost of the bad guidance an initial slow-down. For example, in the P4P field tests, we used P4P guided peer connections first, but with two elements that ensured interconnections: 10% of peer connections remained random, and peer discovery through peer-exchange.

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

----- Original Message -----
From: "Enrico Marocco" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Sent: Thursday, February 26, 2009 10:50:09 AM (GMT-0500) America/New_York
Subject: [p2pi] Mythbustering P2P traffic localization

Hello folks,

we have just submitted a draft that tries to summarize many discussions
about possible effects (and side-effects) of P2P traffic localization:
http://www.ietf.org/internet-drafts/draft-marocco-p2prg-mythbustering-00.txt

The document is very early and the conclusions may be controversial; any
comments, feedback and contributions to improve it will be greatly
appreciated.

Apologies for cross-posting, I'm sending this email to all the lists
where some of the discussions happened; please consider addressing any
follow-up to p2prg only.

-- 
Ciao,
Enrico

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 27 Feb 2009 12:09:07 -0600

[... Took p2pi off; that is a dormant list now ...]

> Nice write-up.

Laird: This is great feedback -- exactly the sort we were hoping to
have.  As Enrico said in his email, the conclusions were
deliberately left "controversial" so we could start a dialog.

> I would shorten the definition of 2.5 "Surplus Mode" to "The status
> of a swarm where the upload capacity exceeds the download demand".
> You could also call this "well seeded".

Sure.

> I would change 2.6's title to "Paid Transit" to be a bit more
> explicit about the distinction between it and peering ("direct
> connections").

OK.

> In 4.1.1, I wouldn't conclude from one test that "the collected data
> also indicate that fine-grained localization is less effective in
> improving download performance compared to lower levels of
> localization", because additional "tuning" of the fine-grained
> guidance could well produce superior results to course grained
> guidance.

We are not concluding as much as observing this phenomenon in
Section 4.1.  The last time I had an (email) conversation on this
with the fine folks from Comcast, they along with Yale were
trying to figure out the reason why this turned out to be the
case.  Ostensibly, some more results will be forthcoming on
this in the form of an updated Internet-Draft.

> Also related to this, I would point out that it's important that
> applications not use network guidance as the sole determinant of p2p
> data exchange. [...]

Yes, true.  We should probably note this somewhere in the
document.

> In 4.2, "imposing locality when only a small set of local peers are
> available" I would suggest that network guidance should never be used
> to exclude available peers, but simply to prioritize the order of
> connection/data exchange. [...]

Good point worth documenting as well.

> To elaborate on 5.1, what we observed is that while the total uplink
> utilization did not change, there was a significant reduction in the
> uplink data sent off-net, balanced by a matching increase in uplink
> data sent on-net. For example, Comcast customers served more data to
> each other, and less data to the rest of the internet.

 From a bandwidth perspective, does that make a difference?  After
all, the uplink bandwidth is still utilized whether or not
the destination is a peer in the same network or a peer that
incurs settlement charges.  No?

> Related to 6, note that guidance can be applied to inter-ISP
> connections, [...]

OK.

> Related to 7, in the last P4P field test we had a wholesale provider
> and a retail ISP both participate, which raised the question of how
> the 'overlap' was addressed. We use the rule that the longest IP
> address prefix match determined the source of the guidance, which
> resulted in the users within the retail network to receive guidance
> from the retail ISP's iTracker, and the other users within the
> wholesale network receive guidance from the wholesale ISP's iTracker.
> We also demonstrated that the wholesale ISP's iTracker could
> internalize traffic within the wholesale network in a similar manner
> to retail ISPs. This was not analyzed from an economic perspective.

I do not think this was described in
draft-livingood-woundy-p4p-experiences-02, was it?  In any case,
this is good to know.

> Also related to 7, if ISPs start providing guidance that manipulates
> p2p data flow in ways that significantly degrade application
> performance, it is likely that applications will either stop using
> the guidance or learn to do so selectively.

Yes, of course.

> In 8, I agree that this is an area for continued research. While all
> of the research on this front has simulated restricted peer
> inter-connections based on locality, I would suggest that [...]

OK.

Thanks, Laird, for a detailed read.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/