Re: [Pearg] Measuring latency in IP privacy architectures

Antoine FRESSANCOURT <antoine.fressancourt@huawei.com> Wed, 10 November 2021 13:21 UTC

Return-Path: <antoine.fressancourt@huawei.com>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42F43A0FC5 for <pearg@ietfa.amsl.com>; Wed, 10 Nov 2021 05:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVlB-fsrmu1l for <pearg@ietfa.amsl.com>; Wed, 10 Nov 2021 05:21:29 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A887F3A0FCC for <pearg@irtf.org>; Wed, 10 Nov 2021 05:21:28 -0800 (PST)
Received: from fraeml706-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Hq58K3fBgz67yPg; Wed, 10 Nov 2021 21:21:05 +0800 (CST)
Received: from lhreml732-chm.china.huawei.com (10.201.108.83) by fraeml706-chm.china.huawei.com (10.206.15.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Wed, 10 Nov 2021 14:21:25 +0100
Received: from lhreml726-chm.china.huawei.com (10.201.108.77) by lhreml732-chm.china.huawei.com (10.201.108.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Wed, 10 Nov 2021 13:21:24 +0000
Received: from lhreml726-chm.china.huawei.com ([10.201.108.77]) by lhreml726-chm.china.huawei.com ([10.201.108.77]) with mapi id 15.01.2308.015; Wed, 10 Nov 2021 13:21:24 +0000
From: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
To: Tommy Pauly <tpauly@apple.com>, "pearg@irtf.org" <pearg@irtf.org>
Thread-Topic: Measuring latency in IP privacy architectures
Thread-Index: AQHX1jRmebVL9vKAJ0Gx9gFJt5ZMIKv8vNlQ
Date: Wed, 10 Nov 2021 13:21:24 +0000
Message-ID: <4a572a6067b841d5809b9cda9e8315b6@huawei.com>
References: <036D2F47-3479-457A-AE30-9C117D75D8FB@apple.com>
In-Reply-To: <036D2F47-3479-457A-AE30-9C117D75D8FB@apple.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.201.119.88]
Content-Type: multipart/alternative; boundary="_000_4a572a6067b841d5809b9cda9e8315b6huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/hlGXJMnmie9-VBEbfJrMDMpVelM>
Subject: Re: [Pearg] Measuring latency in IP privacy architectures
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 13:21:34 -0000

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]
Sent: Wednesday, November 10, 2021 2:11 PM
To: pearg@irtf.org; Antoine FRESSANCOURT <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

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