Re: [Pearg] Measuring latency in IP privacy architectures

Luigi Iannone <> Wed, 10 November 2021 17:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 711DC3A11E0 for <>; Wed, 10 Nov 2021 09:21:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YC1CQtf4XoFC for <>; Wed, 10 Nov 2021 09:21:12 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F5053A11D8 for <>; Wed, 10 Nov 2021 09:21:12 -0800 (PST)
Received: by with SMTP id p3-20020a05600c1d8300b003334fab53afso2337741wms.3 for <>; Wed, 10 Nov 2021 09:21:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UEeTY1HzGyRMf11MrOvCgn63qu+HvbSUgui+7SGeelg=; b=bgWcNoXoJf7RLr4DavLopvuBAeB2BNMCIeCDj/yEUJDhzg/5ToeRDKx59Hg00bZHTV SoCHTKeVL7ey11fz+wbHe77fpHEIS9GQ+dRfLuyGmaGCxg3ocnMZECtwgouAmHFtj5B1 x5boVykFxKxbzTtfmsEfj+KIICJFVif9jvwpRG0gqBqnHyXPdA+eIBGjQYJirN7lCUD8 JLKRKDAfNlvjvhlW7pXvZme2aFqw2bcg8+7EL+eEViMrmJF1QYnOkpJ9Y5HHQzvxMHA5 IA7mIlXxOtBD0jK0lM8fufUbZ8WD2yCBe3QTofkTLkpWsnnEUtTcxCIS1GY80gmNon3m yjtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UEeTY1HzGyRMf11MrOvCgn63qu+HvbSUgui+7SGeelg=; b=UfTM2rhA/M0cAhG4DAqqWk6JcxnBfzPJCWnoeb4cOwMEQfQLypRFUOitt2Qcg+jCTO zoJwzwSkx/cj3iAisSmEQEuZzBhsviizuNkKMckwfggRFh9mUnEBYfe1SeA074i0pZaW FB9dIhMq93vdJdkRSazs7jCwH3z4eJ5P/UjftgfvRby9GQcNr4cLJU3WNBcaY0AKpxxf r8ce2qhZSFMgUtMZkoM4wcV08zG2r8e6ttIzGrdVH36+cSLEVPm37VwuRmSnGNDmtXoR Na4Ea8jPiMBruqdaVWuOk/t9Owo4r0XzUYTnVJ1O0c4nircpFW7R4UvxtwO8BRRGsKNr fulw==
X-Gm-Message-State: AOAM5325EqmpHvxmrjDLN5cW2gl1jjJnsvvGdbKF/qN5NTtuetyaoXHx XkoFhDbv0ijvRIbT20L2zY52qQ==
X-Google-Smtp-Source: ABdhPJx+oTaAvbLYVSDmznykEvheJr65+rdc3yTMResz3AIZoj26o/2BTZTs6afMI/v4YPpv8uZwJQ==
X-Received: by 2002:a05:600c:1d97:: with SMTP id p23mr873634wms.144.1636564868690; Wed, 10 Nov 2021 09:21:08 -0800 (PST)
Received: from ([2a01:e0a:1ec:470:9d94:23d6:893d:2490]) by with ESMTPSA id d8sm438980wrm.76.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Nov 2021 09:21:06 -0800 (PST)
From: Luigi Iannone <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_81AA4DFA-9607-479F-9747-3854A27F64CC"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.\))
Date: Wed, 10 Nov 2021 18:21:04 +0100
In-Reply-To: <>
Cc: Antoine FRESSANCOURT <>, "" <>
To: Tommy Pauly <>
References: <> <> <>
X-Mailer: Apple Mail (2.3693.
Archived-At: <>
Subject: Re: [Pearg] Measuring latency in IP privacy architectures
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Nov 2021 17:21:19 -0000

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?



> On 10 Nov 2021, at 14:30, Tommy Pauly <> 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 < <>> 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 [ <>] 
>> Sent: Wednesday, November 10, 2021 2:11 PM
>> To: <>; Antoine FRESSANCOURT < <>>
>> 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!).
>> <>
>> 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 mailing list