Re: [p2pi] Mythbustering P2P traffic localization

[Laird Popkin <[e-mail]>]

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: [phone]

----- Original Message -----
From: "Enrico Marocco" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi