Re: [Pearg] Measuring latency in IP privacy architectures

Eric Rescorla <ekr@rtfm.com> Wed, 10 November 2021 13:27 UTC

Return-Path: <ekr@rtfm.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 C4B833A106D for <pearg@ietfa.amsl.com>; Wed, 10 Nov 2021 05:27:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.com
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 OwvvCZw5cokL for <pearg@ietfa.amsl.com>; Wed, 10 Nov 2021 05:27:15 -0800 (PST)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4463A1021 for <pearg@irtf.org>; Wed, 10 Nov 2021 05:27:15 -0800 (PST)
Received: by mail-il1-x130.google.com with SMTP id i9so2456805ilu.8 for <pearg@irtf.org>; Wed, 10 Nov 2021 05:27:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=msKQvzRT56GXLZYJLWNwppdx5eEfa/i2qHwLWxIQmBY=; b=ABX3KNg8ucgLp/xbEwOe7+Rt4kwV6E+sLIgE5DuNNCEKXMUWAmEXvZpvazj0Eh4USA B5EZTjg3vuKF/MP1LEhkQ39PhmQnIgtBJIJ8fu87zkKfAn2gWQwSUJAlK4kdACCk3o3X fqAnb49bc38jm5Zbe/V2ZIe1iUnHTdcuq4jn1UVSmWb/C4hX65Evdz9MOwopAuOBSf3i GIzRaMpVD4Fdc8so3GdICuNWJbMTU1QqW87gx8mLr8TwOaGm3reeiL8OP/fW8I7LZqGt kKesE0MnrcBKrXWp6EzdddcKYLbLFd5eVMfWpNoyPfNVfOSL2NoV/3EJQ28CYIWpfxxs x0Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=msKQvzRT56GXLZYJLWNwppdx5eEfa/i2qHwLWxIQmBY=; b=OgGz07+y0xA97kXWBFr63X1Nb5CefQ+IyMClHHdTleAropbeUoBdcqlkzac/ga9wn2 nPXj4OcYn0HW+Vd1LD4qUNHFNTc3zaZWE1eS3JtcHs7xzctsK3RJKQ/JRJ5WdyfJRA36 Bz0KSwYqWY+FORs9Ld+EpKqXWtLCk2gRXEzjKngINbPYGUaiiX0v347uF5To8mM6s9kJ 5C5seZ51XeTBO05qvNjB4sHxbudeF1hK7gbLcKYmb9d6Rx2XE7v4rX9PzWO/x+nPmxt+ PmhgMoGcvPqMNdtK8TzJm8RAXRCERk4Ky5FOt+ro9KaOC2L8WGfHmvmJ/WNeyLDhunPb dksw==
X-Gm-Message-State: AOAM532FCrTPD1QK7HCuC1TKWB+htDUEesbO+e6VDfQbRrpI/l+tFJrN TbPxDWW4Qu/6qOrNOyV5Dhxi1pNU19KT+UKdbjSKZA==
X-Google-Smtp-Source: ABdhPJzynwsjSpJciHx1HN74ojJ6JoWpZUdv7jGZlAp6SIih2JfN6kdg3oMbMEasjFn0fHaYc6GX/ypdz2CEUbw+H0o=
X-Received: by 2002:a05:6e02:1b8a:: with SMTP id h10mr11432571ili.219.1636550832626; Wed, 10 Nov 2021 05:27:12 -0800 (PST)
MIME-Version: 1.0
References: <036D2F47-3479-457A-AE30-9C117D75D8FB@apple.com> <4a572a6067b841d5809b9cda9e8315b6@huawei.com>
In-Reply-To: <4a572a6067b841d5809b9cda9e8315b6@huawei.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 10 Nov 2021 05:26:36 -0800
Message-ID: <CABcZeBOOYTdO9MQgC0Di-MqpU6NmkLM-NcViEkDZKvM+eVXryA@mail.gmail.com>
To: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
Cc: Tommy Pauly <tpauly@apple.com>, "pearg@irtf.org" <pearg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000000936c905d06f2fdf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/Z3XdZ0hXhwNmg3ay3RbpfVWgOBU>
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:27:29 -0000

On Wed, Nov 10, 2021 at 5:21 AM Antoine FRESSANCOURT <
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.
>

I don't believe that this is correct. All of these systems use asymmetric
cryptography for connection setup followed by symmetric cryptography for
data encryption.


>
> 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 don't think this would be accurate either.

-Ekr


>
> 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
>
>
> --
> Pearg mailing list
> Pearg@irtf.org
> https://www.irtf.org/mailman/listinfo/pearg
>