Re: Quic: the Elephant in the Room

Eric Rescorla <> Wed, 21 April 2021 01:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 758453A10F2 for <>; Tue, 20 Apr 2021 18:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VW65VAbBuiSb for <>; Tue, 20 Apr 2021 18:28:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6273E3A10F0 for <>; Tue, 20 Apr 2021 18:28:19 -0700 (PDT)
Received: by with SMTP id l21so3856291iob.1 for <>; Tue, 20 Apr 2021 18:28:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S+VX11QJd9t2LshMllZSsFa42sAfBzzrGnWgGvMmoDI=; b=mvNFJsxIu3Bcnd//KBVE8WLG4pTCn9V+qZtPF8gYgKaikbsu09YlvpfAFY0k6SzsXO NP8CWUYt7kwFqegud6+gOuR1mHw0/LdahtoWJp12B5BEBbjxRJ8dGjjklfg/8m9kU1uT S4kMnZkoX0TRj3tEPJPcMRxX7c4yx59Km50bIhmKsFj+9scZT6ogNCf4sKoDneggBEnh VaxlrpVVd8jgy3ji/MBHrqcxFg5PhejzmFDFvHQxl3JceKDrUZKkv1afWeVGjzxdGzqV YOkwqugBLra3w3fZTDo9un9zJj7rS7ZZfvw8w7/ImTyjHS9U5tQaGiSPjTWjWkh8OHFi oDhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S+VX11QJd9t2LshMllZSsFa42sAfBzzrGnWgGvMmoDI=; b=R60H8DW8ERdVAN9C48lu7fbIEmYpyt8zupDgIIm/Oc6fDUre1eiadSNVPAyfVZrXGC iMnRnzK/WENCD8dVKxwr1Wihcgu0AiRxeZ1na8wpWJvxQ0kv+oKW+PJKlVmAmQ/gtLrJ hSyTDeptk4g5qFFS8FZ4ULvfRWxp42jlNnpdlE0kPheEuHDNq3oZi1Vi//XXBWfHEB2s ZyR1jhRBepW7Z0lkXBVZW+AfgGx68s5DDv34iAUrn/D76eGCxD77ZBHgOJgaKM+slb/3 nhoIo1Oy6y2IkLFpuWEmDRifT9pYRwYujTZ+vgRhPlLDz+5snBkwJqPGkcL5eBMmNcYA 3YuA==
X-Gm-Message-State: AOAM533Yhd4SYJf5nJGyL5/hlSYBGOdfcFl+JUsvtgwMuB18FSNue3US /HiJ/1ZfwaqrN8FOQ48PZwTDexnFhtnyN+/nQmKQjA==
X-Google-Smtp-Source: ABdhPJxkvHM5SeKcIZgLKQj8ZWWF57rY72L3XjJZDR/Z6ieN8QBFLr6SfW1HYIK/Tj5c0g+QmgjVIZpc+oAjtCjdyfY=
X-Received: by 2002:a02:340c:: with SMTP id x12mr7579979jae.64.1618968495728; Tue, 20 Apr 2021 18:28:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Tue, 20 Apr 2021 18:27:39 -0700
Message-ID: <>
Subject: Re: Quic: the Elephant in the Room
To: Michael Thomas <>
Cc: Phillip Hallam-Baker <>, David Schinazi <>, Matt Joras <>, IETF QUIC WG <>, Lucas Pardue <>
Content-Type: multipart/alternative; boundary="000000000000173f9205c0717ab0"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Apr 2021 01:28:24 -0000

On Tue, Apr 20, 2021 at 6:10 PM Michael Thomas <> wrote:

> On 4/20/21 5:43 PM, Phillip Hallam-Baker wrote:
> On Tue, Apr 20, 2021 at 4:18 PM Eric Rescorla <> wrote:
>> To follow up on what David Schinazi says, the primary determinant of
>> handshake latency for a protocol like TLS or QUIC is not the total number
>> of packets but rather the number of round trips. Of course these are not
>> unconnected because you don't have infinite congestion control window. This
>> is especially true for QUIC because the server is limited to 3x the
>> client's initial flight as an anti-amplification defense [0]. However, in
>> practice, most server certificate chains will fit within a single QUIC
>> flight, as documented in this post by Patrick McManus from Fastly [1]. And
>> if you use RFC 8879 certificate compression you should capture almost all
>> of the rest. For this reason, it seems unlikely that the TLSA approach you
>> propose would significantly decrease setup latency.
>> This is not to say that there is no room for improving latency via keying
>> material in the DNS, but the purpose of that would be to allow the client
>> to send data in its first flight (aka "zero-RTT priming"), not to reduce
>> the size of the server's first flight
> If you win at Pinball, you get to play again.
> I decided not to engage in QUIC fairly early on. Not because I didn't have
> any relevant ideas but because the scope was already large and my ideas
> would tend to make it larger when was needed was to make it narrower.
> As the work continued, I realized that QUIC is very different from TLS and
> TCP: We don't have to try to make one size fits all. We can have separate
> transports optimized for Browsing, RTC and transactional services.
> This is a picture perfect example of the power hungry working group chairs
> executing the infidels that have been the subject of many recent talks on
> the IETF list. this is exactly why nobody wants to work with the IETF.
There is a certain irony that you are saying this on the mailing list for a
protocol whose github repo has somewhere over 100 separate contributors
(i.e., people who actually submitted PRs and had them accepted). This seems
to me like a good example of a case where quite a few people wanted to work
with IETF.

> I predicated this on the IETF list with Keith Moore and turned out exactly
> as I expected. And it took less than 24 hours. Thanks for making my point
> Lucas Purdue. You are part of the problem, not part of the solution.
Having read the thread, I think the chairs handled this appropriately. You
made a suggestion, several people, most notably David Schinazi told you why
they didn't think that it was an improvement, and you responded by
complaining that David didn't want to run an experiment that he didn't see
value in. Lucas politely asked you to take it elsewhere. With that said, if
you in fact think that Lucas behaved inappropriately, I encourage you to
take it up with the ADs.