Re: Quic: the Elephant in the Room

David Schinazi <> Tue, 20 April 2021 17:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFCB73A0BDE for <>; Tue, 20 Apr 2021 10:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 euhQPIoyM1vX for <>; Tue, 20 Apr 2021 10:20:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F3EF3A0BED for <>; Tue, 20 Apr 2021 10:20:34 -0700 (PDT)
Received: by with SMTP id v13so6444870ple.9 for <>; Tue, 20 Apr 2021 10:20:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kkv9QUmmCIreaTApeRoQoyfUT6AkCQmNe63jAMHNZHg=; b=ZxQ9kn3JENGvderRpxj4j8i1z9jZv4h9rjQ5tjjE1aO62Uyk6bbbuXVtdUpbpDgPg5 IQgGxeubWnVhjYjKGQvzR0buGQi9ixpuUCUOAPS794SEihT3KTRQQQHd9ghxbwvrPikL wnxqTd9vhyoekl1jsoNlPWAVC10ISqm/PiIOxa120VrLpegfLodfjT0L1VIXkV56VvPC +ihGITx7KWE+GzE036JuAeLoR87cbKuZBwoJ2r7hUys9zROuwtSmhYcBhGJXzfnqGoxl aJ9WtPANNzLB6s0z/J5r+EXJT+Bnn7lzc8E8QmZWpAtoJukl6Sp6FMl+VbxoHINpS5qG TKmQ==
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=Kkv9QUmmCIreaTApeRoQoyfUT6AkCQmNe63jAMHNZHg=; b=T7a9hu3qS5HAqEhhubwjh+/CUqVPmoSG7/Dly+waepqYi7sls7AiTxiRj7ZOxMb5FE P/G7Q6NDrdGTn0b97NoRpJDAoXhUtUwKStT0hfm8BgZrSEyXhwRghOXW8hcmWpuVuNEv QFsvsHIxAkvr759rCwBRxmzx/rqWmruPRganAXFZm563Y8lcTYEIjTC9FkGoutFh/vq+ CZ8Nf1Jc6eKVzHnkBQVwic8MgkAI0dtdkWgqYA+gKdURgkDfkTJAH2pm3VBR1MijynoN 7O+wTFpHmKXOv9RAUoETU2gRgS+YyJpNbpdC4HNjlN8hzZBwG0uvA6n2D2EbDc492PGj dvEQ==
X-Gm-Message-State: AOAM531nuco+rfJzszuO2fh94xV9i9PAn5h0natTM/Vif3uokM4dOj9q C10pxFtXXRmEvoZm8tKWh3VoQpkXSH3E9xCn01Y=
X-Google-Smtp-Source: ABdhPJzBWBPRY/q7OaYu/roTE6pM1McEUtPPqzfLytXziNK8HqPdoeeQ7uFU4VaK84vjooAinxPpKYRLwFzk/Xm4VmE=
X-Received: by 2002:a17:90b:390f:: with SMTP id ob15mr6072524pjb.100.1618939233545; Tue, 20 Apr 2021 10:20:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Tue, 20 Apr 2021 10:20:22 -0700
Message-ID: <>
Subject: Re: Quic: the Elephant in the Room
To: Michael Thomas <>
Cc: Lucas Pardue <>, IETF QUIC WG <>, Matt Joras <>
Content-Type: multipart/alternative; boundary="000000000000edb08f05c06aa9bc"
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: Tue, 20 Apr 2021 17:20:40 -0000

Cutting down the number of packets was never a goal for QUIC.
The goal was to save round trips in connection establishment,
as that significantly impacts user-visible latency. The number of
packets only slightly increases the probability of loss during the
handshake which can be correlated to user-visible latency, but
much less.

I'm not saying that a 3-packet handshake would be bad, I'm saying
that it's not worth boiling the ocean to remove 2 packets. I'll also
note that your proposal doesn't fully reduce the number of packets
because you still need a DNS TLSA request and response, and loss
of those is much worse as DNS retransmissions are less optimized.


On Tue, Apr 20, 2021 at 10:15 AM Michael Thomas <> wrote:

> On 4/20/21 10:07 AM, David Schinazi wrote:
> Hi Mike,
> I read your blog post, and I failed to find what problem you're trying to
> solve.
> The fact that some handshakes spend a couple packets on certificates?
> We can actually quantify the user-visible impact of the handshake size, and
> from everything I've seen this particular topic isn't impactful enough to
> solve,
> apart from ensuring support for RFC 8879. It's even less realistic if the
> solution involves the minor task of switching PKIs and roots of trust.
> Speaking as one of the QUIC tech leads at a "Google-like company", I can
> ensure you that we don't spend time on experiments that don't benefit
> users.
> It seems that you have a solution in search of a problem here.
> I thought the entire point of QUIC (aside from HoL blocking) was to cut
> down the number of packets needed to start a connection. From what I can
> tell, it takes it from an 8 packet exchange to a 5 packet exchange. If you
> were to use a DANE-like solution that would be a 3 packet exchange most of
> the time. Why is a 5 packet exchange good but a 3 packet exchange not?
> Mike
> David
> On Mon, Apr 19, 2021 at 3:39 PM Michael Thomas <> wrote:
>> On 4/19/21 3:33 PM, Lucas Pardue wrote:
>> > I'm struggling to see what the problem statement that is unique to the
>> > QUIC protocol is.
>> >
>> > That certificates can be large is not new information, it was a prime
>> > motivator for RFC 7924 [1] and RFC 8879 [2].
>> >
>> > Operators can, of course, experiment with new optimal ways of doing
>> > things. The broader IETF community is likely interested in the outcome
>> > of such experiments. Since QUIC version 1 uses TLS, any changes that
>> > stand to improve a QUIC handshake would likely be applicable to TLS
>> > too. So the concept of replacing current TLS mechanisms with the DNS
>> > doesn't seem to be something the QUIC WG should be leading. Should
>> > such work identify QUIC protocol design evolution or extension, then
>> > it could be suitable for WG consideration.
>> >
>> I'm not asking this working group to do anything. Just socializing
>> something that generated a lot of discussion on the IETF list that might
>> be of interest to the Quic community.
>> Mike