Re: [Pearg] Measuring latency in IP privacy architectures

Following this short exchange, I wonder if it would make sense to document how to make a fair comparison among different privacy solutions.

Sot to be able to understand in which use-case/scenario they excel.

Would it be interesting?

Ciao

L.

> On 10 Nov 2021, at 14:30, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
> 
> Hello Antoine,
> 
> Thanks for the clarification! Good to know that this was theoretical. One thing that probably should be clarified is how public key cryptography is used in the various solutions. For example, in iCloud Private Relay, we use RSA Blind Signature tokens only as an HTTP authentication method into the relay at the start of a connection, which only requires the relay to do a verification of the user once for a proxy connection that can end up being reused for thousands of end-to-end proxied connections. Thus, the impact of setup (QUIC/TLS handshake to the proxy) is quite minimal. This has no impact on per-packet costs.
> 
> Changing your graph to cryptographic load would be an improvement, but I think that’s not a clearly linear axis, since we still need to distinguish between per-tunnel and per-packet overhead.
> 
> Best,
> Tommy
> 
>> On Nov 10, 2021, at 5:21 AM, Antoine FRESSANCOURT <antoine.fressancourt@huawei.com <mailto:antoine.fressancourt@huawei.com>> wrote:
>> 
>> Hello Tommy,
>>  
>> As I am the author for this slide, I feel I am best suited to answer you.
>>  
>> My perception of the latency of the solutions I am presenting is for now rather theoretical. As Private relay and Gnatcatcher use public key cryptography algorithms, I made the assumption that the computation time dedicated to cryptographic operation is larger in this case that in TOR which uses symmetric key cryptography.
>>  
>> Yet, I agree with you that presenting this as latency while I can’t present figures might be misleading. To address this point, I propose to replace “latency” with “cryptographic load” in this schema to be more accurate with regards to what I really mean. Would you be OK with this change?
>>  
>> I agree with you on the performance / latency methodology we should agree on.
>>  
>> Best regards,
>> 
>> Antoine
>>  
>> From: Tommy Pauly [mailto:tpauly@apple.com <mailto:tpauly@apple.com>] 
>> Sent: Wednesday, November 10, 2021 2:11 PM
>> To: pearg@irtf.org <mailto:pearg@irtf.org>; Antoine FRESSANCOURT <antoine.fressancourt@huawei.com <mailto:antoine.fressancourt@huawei.com>>
>> Subject: Measuring latency in IP privacy architectures
>>  
>> Hello,
>>  
>> I was looking at the slides for one of the PEARG talks for tomorrow, and had some questions about one of the graphs. (I likely won’t be able to attend the meeting due to a conflict, so I thought I’d ask here!).
>>  
>> https://datatracker.ietf.org/meeting/112/materials/slides-112-pearg-state-of-the-art-on-privacy-preserving-techniques-used-at-the-network-layer-00 <https://datatracker.ietf.org/meeting/112/materials/slides-112-pearg-state-of-the-art-on-privacy-preserving-techniques-used-at-the-network-layer-00>
>>  
>> There’s a slide titled “Positioning SoA projects on a map”, with two axes—“attack class” and “latency”. While the “class” is a relatively subjective measurement, the latency metric should be pretty straightforward. I assume that the latency axis goes from lowest-latency on the left, and highest-latency on the right. There weren’t any numbers provided, but I was very surprised to see that both Gnatcatcher and iCloud Private Relay were listed further to the right than TOR! In the case of iCloud Private Relay, which I work on, our overall metrics show that the average page load time for the browser going through the relays is actually faster than going direct for most parts of world. To that end, our effective latency is quite good. Can anyone share insight into what the methodology was behind this graph?
>> 
>> 
>> More generally, if we’re discussing latency for IP privacy solutions, it would be good to agree on what methodology is appropriate across very different technologies. IP-tunnelling can end up requiring more round trips for typical workflows (due to DNS and TCP handshakes over the tunnel) than CONNECT-style proxying (which can end up doing DNS+TCP+TLS in one round trip). That changes the experience of latency, in addition to the actual round-trip-time between hops.
>>  
>> Best,
>> Tommy
>>  
>> -- 
>> Pearg mailing list
>> Pearg@irtf.org <mailto:Pearg@irtf.org>
>> https://www.irtf.org/mailman/listinfo/pearg <https://www.irtf.org/mailman/listinfo/pearg>
> -- 
> Pearg mailing list
> Pearg@irtf.org
> https://www.irtf.org/mailman/listinfo/pearg