Hi, Lucas, On Sat, Apr 10, 2021 at 11:26 AM Lucas Pardue <[email protected]> wrote:
> 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 :-) Best, Spencer > Cheers, > Lucas > QUIC WG co-chair > > > On Sat, 10 Apr 2021, 12:09 JP Sugarbroad, <[email protected]> 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 <[email protected]> >> "Please let me know if there's any further trouble I can give you." >> -- Unknown >> >
