From taralx@gmail.com Fri Apr 9 20:52:56 2021 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3F63A1FEA for ; Fri, 9 Apr 2021 20:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 m80z-cFJRPK0 for ; Fri, 9 Apr 2021 20:52:52 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 D2BA13A1FE2 for ; Fri, 9 Apr 2021 20:52:51 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id e186so7955570iof.7 for ; Fri, 09 Apr 2021 20:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EJDBwbyMjBI9Cr4OkWBDiT38Qh9EOluVlxJV1Q0WHpw=; b=eT4xSh8X7o7tHw6EeSx8Gx9BdA4M4hcCiR7BlyKNjSHUAGnicdMyZY4aDo1IV43mQg 1L0pfpjECu63z3y3DyAl8h5f7Jf2nbPm2yxKnj/oAoexusbt/FICg5ccfBfBNyETtZHz jAjdCI6TKID5q8KaJ3kwSJozrjhRNTJJiiCs/L8N5djGZcKT5Pffj/7m4vAcBadQ8rtP afwGOvvLomP6Drmsu3wrA5nt1kgk6kbqPnZlKdXcbnCoplCK791F70fBfFCY8JwHe3Q0 7GRegsPaH5QvvRcet/YuoE55gEolmaYXIUpZ1iJOJHxudIsJ4dglxhH4xdhB9TScduWP BIlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EJDBwbyMjBI9Cr4OkWBDiT38Qh9EOluVlxJV1Q0WHpw=; b=Q02HdAnnOqxvIGJPmfxfHn2g19HKd5K2cXDvPWASz3OWvoOlt/HXlwyInpXt1qoWr8 2+tWQQHVTKkkrQ0POimlPnZ1RQEaMiQr1G0Swym7XtTkDDLrfDJgIfSbUPcbwaG8ISl9 cgFBof2AQN+pKEH90mTJLK9n17enXJe3en9+2UJ2jXTmIzGHrbhQgkrXlp7a2it64duk 96rzeBgPDgYOmV3caelAmf5inkR1WjEsSl9fnP46amnfCDi9m2HbvYJ9BVQSL7Az2d+0 GKPtXfiJDAXEMgq1cL7ieyFPWSfFfrLYQn4GUDyCQ9CrChLTdgzktieHLChF1mllE9Tq eRzw== X-Gm-Message-State: AOAM53139vlYAQ72WrcfX9F5drCkAsVEhmmCAs2y8XPUI8Zx/3pwgstY b9iKMoXlhBs3BlRAdMYX4CthttC3YQNUR8Q5v8x1T1Uu2GBzKA== X-Google-Smtp-Source: ABdhPJyAlsPL3KdD1a97IkppD/pcjS8HjisTLdz0K4SABhCpqBOEaiajbnj0qC7fO9MX6BRqISXS1VwZ/DrBjdReGv0= X-Received: by 2002:a05:6638:2603:: with SMTP id m3mr17683762jat.64.1618026769819; Fri, 09 Apr 2021 20:52:49 -0700 (PDT) MIME-Version: 1.0 From: JP Sugarbroad Date: Fri, 9 Apr 2021 20:52:37 -0700 Message-ID: Subject: Experience of a new implementor with the latest working drafts To: quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000da2d3d05bf96360e" Archived-At: X-Mailman-Approved-At: Sat, 10 Apr 2021 04:08:53 -0700 X-BeenThere: quic@ietf.org 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 04:00:02 -0000 --000000000000da2d3d05bf96360e Content-Type: text/plain; charset="UTF-8" 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 --000000000000da2d3d05bf96360e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So I decided to poke my head in and answer the question &q= uot;what does a bare minimum compliant HTTP/3 client look like?". The = answer so far has been... slow going.

I started with &qu= ot;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 In= itial packet fully conforming with the specification, the server proceeds w= ith the handshake", so Initial is first? Ok.

= What goes in the Initial packet?

Section 17.2.2 re= ferences "destination connection id", "source connection id&= quot;, "token", "packet number", and "payload"= ;. Token is covered right there, and it seems to be optional except for som= ething 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 Connec= tion IDs", but isn't very useful. Section 5.1 says "A zero-le= ngth 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 ski= mming over all the frame talk since obviously I can't exchange frames y= et. Reading through the rest of section 5, there's nothing in here. Tur= ns out the answer is buried in the middle of section 7.2: "When an Ini= tial packet is sent by a client that has not previously received an Initial= or Retry packet from the server...". This took me literally fifteen m= inutes of searching to find. I was significantly impeded by the split betwe= en sections 5 and 7.

Ok, what goes in Version? Can= 't be zero, that's version=C2=A0negotiation. Finally found it in th= e preamble of section 7. That's *certainly* not where I'd expected = to find it at all.

Eventually I realized that seve= ral of the remaining fields are actually defined in 17.2, and it is necessa= ry to read QUIC-TLS to understand some special mangling that happens to all= packets, even the first ones. (Why do Initial packets need header protecti= on? Unclear.) Basically what I'm realizing is that these documents cann= ot be treated as two standalone layers of a protocol but are instead intert= wined in a fairly complex way. :(

In the end, it t= ook 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 info= rm future changes to the document.

(It would be ni= ce to have more cross-references. An example packet flow that covers all of= the packet details with references to the sections that constrain them wou= ld be *really* great. Figure 5 is good, but doesn't talk about things l= ike connection IDs.)

--
JP Sugarbroad <taralx@gmail.com>
"Please let me know if there's = any further trouble I can give you."
=C2=A0 =C2=A0 -- Unknown
=
--000000000000da2d3d05bf96360e--