Hi Yan,
Thank you for the reply - see below:
On Mon, 26 Oct 2009, Wang Yan wrote:
"ISP doesn't need P2P operational details, which can reduce the risk of
disclosing P2P privacy."
What "P2P operational details" do you envision are being sent to the ISP? In
P4P, no such information is delivered to the ISP -- it simply provides the
PID and pDistance Maps.
What we talk about in the draft is compared to PROXIDOR or path rating. CPID
solution is based on P4P. I also think P4P and CPID can get the same
performance regarding the privacy issue, if ISP provides the PID and pDistance
Maps in P4P. However, in terms of workload, especially in the case that a P2P
client is an ALTO Client, I think using full map may cause some pressure to P2P
client. Using CPID, we could obtain cost/pDistance by simple calculation
without much searching or mapping cost. The way using full map here is a little
inefficient than using CPID.
Okay - this distinction about what was being compared wasn't quite clear
from the text, which resulted in my confusion :)
If you are refering to the computational cost, note that there are two
steps before identifying the pDistance between two peers in P4P:
1) Look up the PID via longest-prefix matching for each peer in the PID
Map provided by the ISP. In practice, this only needs to be done once
for each peer (and updated whenever the PID Map changes) since the PID
can be stored in the peer's data structure.
2) Identify the pDistance between the 2 peers by looking up the entry in
the pDistance matrix.
In our implementation, we locally store the PID as 0-based integer, and
the pDistance is a simple 2-dimensional array, so step (2) is only a
constant-time lookup into an array.
In the CPID case, step 1 which includes longest-prefix matching is still
present, right?
"Although the ISP topology information can be inferred by the full collection
of PIDs as P4P, a correct computational function or driver still need to be
obtained additionally to calculate the corresponding cost value."
What prevents a set of peers (or even a single peer) from gathering the full
list of CPIDs, and simply computing the pairwise cost between each one?
Aren't the same costs that the ISP would have delivered in the pDistance
map immediately discovered by the P2P application? If so, what has the ISP
gained in terms of privacy?
Both P4P and CPID can get pDistance map, one is a direct way and another is
indirect by gathering the full list of CPIDs.
P4P provides PID map and we can directly know relationships of IP-PID for all
peers, but it is difficult to get an IP-CPID map because it needs to gather
CPIDs for all peers.
The results may be similar to some extend, but the required efforts are
different.
You are certainly correct that the required efforts will be different.
However, I feel that it is dangerous to claim that the privacy benefits
are higher just because it is slightly more difficult to compute the
pairwise computational costs. The reason I say "dangerous" is because it
can lead to a false sense of security for ISPs.
If peers are able to query for the full list of CPIDs just as they do the
full list of PIDs in P4P, then the computation of all the pairwise costs
is trivial.
If you envision a much larger number of CPIDs such that they are not
provided by the ISP in a full list, then peers can certainly still figure
out the full set. P2P applications have many ways to coordinate today
(e.g., DHT) and some have very easy plugin APIs (e.g., Vuze) making it
easy to query for CPIDs at a large scale. One could even setup a web
endpoint where they could send query results from each vantage point, and
a central entity could compute costs amongst each CPID.
Note that large-scale mapping efforts are not unheard of. For example:
http://iplane.cs.washington.edu/
Thus, this would make it roughly equivalent in terms of privacy to an ISP
exposing many fine-grained PIDs and costs amongst each pair.
I certainly think that the draft's idea of costs computed directly from
PIDs is interesting :) My only comments in this thread are in terms of
the privacy claims related to it.
Thanks!
Rich
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
