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 protected]>
To: [email protected]
Cc: [email protected], [email protected], [email protected]
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 protected]
https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
