I have started to spend time contributing to Neqo, Mozilla's implementation of the QUIC/HTTP3 standard. I got a foothold in the code by attempting to tackle an easy first task. N.B.: Names can be deceiving. In the process, I found a few of the transport parameters of a QUIC connection (values exchanged between peers at the start of a connection) very, very confusing:

  • initial_max_stream_data_bidi_local
  • initial_max_stream_data_bidi_remote

Each of these parameters is described in the standard itself, https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-18.2 but I had a very hard time parsing the semantics of the description. For example, here is the description of initial_max_stream_data_bidi_local from the standard:

This parameter is an integer value specifying the initial flow control limit for locally-initiated bidirectional streams.  This limit applies to newly created bidirectional streams opened by the endpoint that sends the transport parameter.  In client transport parameters, this applies to streams with an identifier with the least significant two bits set to 0x0; in server transport parameters, this applies to streams with the least significant two bits set to 0x1.

That's a mouthful, isn't it? After several hours days of textual analysis, I thought I figured it out and consulted with QUIC experts Robin Marx, Daniel Stenberg and Lucas Pardue (besides being experts, the members of this triumvirate are really great people) to make sure I understood.

As I discussed my understanding of the parameters with them, it became clear to me that I should attempt to diagram the intent of these parameters in a way that might save others the same headache.

If you'd like to use this diagram in any form, please do so. I have licensed it under the CC by SA. I am happy to provide it in other formats as well!

Update: The first version of this blog post included the wrong section of the QUIC spec quoted for initial_max_stream_data_bidi_local. I think it is correct now! Sorry.