[... Took p2pi off; that is a dormant list now ...]
Laird Popkin wrote:
> 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: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
p2p-hackers mailing list
p2p-hackers@lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers
