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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.