Hi Rich,

>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?

Sorry to chime in, I think one difference is that CPID solution turns the
two parameters in P4P (PID and pDistance map) into a single paramter (CPID)
that the client needs to maintain.


Xie Xie,
Haibin

  

>-----Original Message-----
>From: [email protected] [mailto:[email protected]] 
>Sent: Monday, October 26, 2009 5:25 PM
>To: Wang Yan
>Cc: Richard Alimi; [email protected]; Song Haibin
>Subject: Re: [alto] New draft notification: draft-wang-alto-cpid-00
>
>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

Reply via email to