Re: Experience of a new implementor with the latest working drafts

Spencer Dawkins at IETF <> Sat, 10 April 2021 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32FBE3A14A4 for <>; Sat, 10 Apr 2021 09:54:52 -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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 c5R_TQ5eozO5 for <>; Sat, 10 Apr 2021 09:54:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2ABA3A14A2 for <>; Sat, 10 Apr 2021 09:54:49 -0700 (PDT)
Received: by with SMTP id v3so7775851ybi.1 for <>; Sat, 10 Apr 2021 09:54:49 -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=W9F1V8d95MtWAMv+Fe7FqkLaU8L5gih1afLGa9X4208=; b=Wt9o9pNwFEgjQYz5rxEBl75PN/LRRAPlTpDu/W1yyf39nT/XEwjP4+FXeYi5j/nveN n7ZOnAkngGyxr0vusHwYatBvTD1Tf6c+afOf4J4v474T7YV8PgiVeHZNojRaut83bUTQ bJa8H9+7IW5txS2VdrmQpFCEchn8xeukyt7KYRgK32pcYNfAB+TbMq3uB4y2orZ9n7of sOWE7UW9mCGDKfn6Ec0tR+ZynVH4S9jt3QojIITcS+Jhlxipam5UFDeopqxq8V0pFBVU 27NvxFUoeI9cJJ4WkxxheR5GIDFWFmiyBFCcV4d5AObTXBPJ1vmWKJZYf8ddYw0KWyPn ogqg==
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=W9F1V8d95MtWAMv+Fe7FqkLaU8L5gih1afLGa9X4208=; b=IVDSdgEqzY4e9P5WkISqABwOIP9pLhIUr+Jf9S8H48uSGshd4K7vE0reBbyQURGC7r rIYsvWXJP1nIX8uqTFFjmQd8Of55OD6OQp8zWmtXKBZq3NLX4MJ+IgcfkVtkHC36eLrb rPl3LUjC91hlfIeevhpZQncvKWIIfvWWQsVWiXeVMb1Ll2+IIXmhCzpSGwbQVulL0TEG z/QCEAs6fkOK0S8/ov3dSNHbq1nt67e5lI4fmC1mujVsSLRqJhsnOyElLOF4cPSKxv8j jNbYDH8EInMjLDIRJT+gYdlC+fsvNUqfaMfDgToyqxFisADy+x500QpdM9nxORDpZpPN tCQw==
X-Gm-Message-State: AOAM530JcfZtoxoBeTauBUkTg5zFBxNuRioePbV5QzlXrmNonn4/hQrS 7yDPzV3+ZLf69iPmBWbf03o/nnlJVt11LwOhu+E=
X-Google-Smtp-Source: ABdhPJzavnOCf/ghe2He+sxYSqjSCYOG+LNyU09N6I6UBO/GXplEBrUl93wkInM7EZmudyc5WiQ0/aCgGSGDMgh2SzM=
X-Received: by 2002:a25:2443:: with SMTP id k64mr574416ybk.154.1618073687661; Sat, 10 Apr 2021 09:54:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Sat, 10 Apr 2021 11:54:21 -0500
Message-ID: <>
Subject: Re: Experience of a new implementor with the latest working drafts
To: Lucas Pardue <>
Cc: JP Sugarbroad <>, QUIC WG <>
Content-Type: multipart/alternative; boundary="0000000000005fa21405bfa123ec"
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: Sat, 10 Apr 2021 16:54:52 -0000

Hi, Lucas,

On Sat, Apr 10, 2021 at 11:26 AM Lucas Pardue <>

> Hi there,
> Firstly thanks for taking the time to try out QUIC and to write your
> experience as a new implementator.

I echo your thanks!

> QUIC is an always-secure transport protocol. QUIC connections start with
> a combined transport and cryptography handshake. This provides advantages
> but also introduces some complexity to bootstrapping an implementation,
> certainly in contrast to contemporary protocols like TCP or UDP.
> Although QUIC conceptually supports different cryptographic handshakes, QUIC
> version 1 has chosen a design based on the TLS 1.3 handshake. These two
> are entwined and need to be understood in tandem to get an implementation
> working.
> I appreciate some of the specific feedback you've provided. QUIC is a
> complex protocol and the current document organisation is our attempt to
> balance the needs of several constituencies that rely on the QUIC
> specifications. The QUIC documents have now passed WGLC, IETF last call and
> IESG review. Any changes risk invalidating prior review comments or
> established consensus. I'll let the editors respond if they think any of
> your observations might be addressed with trivial editorial changes. As a
> gauge: additional cross reference are likely trivial, moving text or adding
> further examples is non-trivial.
> That said, gathering feedback such as yours is useful in the longer term.
> A future document revision of QUIC v1 may be able to incorporate
> improvements. Or we might take suggestions as a signal that the community
> believes it would benefit from a new document like an implementers
> introdixtion/guide. So again thanks for your time, even if we can't
> directly address things today.

I honestly think a new document is the way to go, if the working group
wants to go anywhere to make life easier for implementers who haven't been
involved up to this point. .

I look forward to hearing people say whether the working group wants to go
anywhere toward that destination :-)



> Cheers,
> Lucas
> QUIC WG co-chair
> On Sat, 10 Apr 2021, 12:09 JP Sugarbroad, <> wrote:
>> So I decided to poke my head in and answer the question "what does a bare
>> minimum compliant HTTP/3 client look like?". The answer so far has been...
>> slow going.
>> I started with "how do I construct the first packet", but the information
>> I needed was scattered. I'm used to being able to pull partial information
>> from an RFC without reading the whole thing, so I skipped around a lot:
>> Do you send an Initial packet or a Handshake packet? Well, section 5 says
>> "Each connection starts with a handshake phase", so maybe Handshake packet.
>> But then 5.2.2 says "If the packet is an Initial packet fully conforming
>> with the specification, the server proceeds with the handshake", so Initial
>> is first? Ok.
>> What goes in the Initial packet?
>> Section 17.2.2 references "destination connection id", "source connection
>> id", "token", "packet number", and "payload". Token is covered right there,
>> and it seems to be optional except for something called a Retry packet.
>> There's also reference to NEW_TOKEN -- it's not clear if either of these
>> tokens is required to be used from here. The payload is also in the same
>> section with "The first packet sent by a client...", which is useful.
>> Connection IDs are a bit more mysterious. Section 5.1.1 is titled
>> "Issuing Connection IDs", but isn't very useful. Section 5.1 says "A
>> zero-length connection ID can be used when a connection ID is not needed to
>> route to the correct endpoint." so maybe they can both be empty? I'm
>> skimming over all the frame talk since obviously I can't exchange frames
>> yet. Reading through the rest of section 5, there's nothing in here. Turns
>> out the answer is buried in the middle of section 7.2: "When an Initial
>> packet is sent by a client that has not previously received an Initial or
>> Retry packet from the server...". This took me literally fifteen minutes of
>> searching to find. I was significantly impeded by the split between
>> sections 5 and 7.
>> Ok, what goes in Version? Can't be zero, that's version negotiation.
>> Finally found it in the preamble of section 7. That's *certainly* not where
>> I'd expected to find it at all.
>> Eventually I realized that several of the remaining fields are actually
>> defined in 17.2, and it is necessary to read QUIC-TLS to understand some
>> special mangling that happens to all packets, even the first ones. (Why do
>> Initial packets need header protection? Unclear.) Basically what I'm
>> realizing is that these documents cannot be treated as two standalone
>> layers of a protocol but are instead intertwined in a fairly complex way. :(
>> In the end, it took me hours just to learn how the first packet works.
>> I'll keep going, but I thought perhaps the feedback on my experience so far
>> might help inform future changes to the document.
>> (It would be nice to have more cross-references. An example packet flow
>> that covers all of the packet details with references to the sections that
>> constrain them would be *really* great. Figure 5 is good, but doesn't talk
>> about things like connection IDs.)
>> --
>> JP Sugarbroad <>
>> "Please let me know if there's any further trouble I can give you."
>>     -- Unknown