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