Add application parameters to QUIC handshake and use it for H3 SETTINGS

[Nick Harper <[e-mail]>]

I propose introducing application parameters to the QUIC handshake and
using this new mechanism for H3 SETTINGS instead of sending them as
the first thing in the control stream. Application parameters would
allow applications using QUIC to advertise or negotiate
application-specific parameters during the cryptographic and transport
handshake. It would guarantee that the client and server have
exchanged their application parameters once the handshake is complete.

Specifically, I’m proposing a new “application_layer_parameters”
transport parameter, which when sent by the client is a series of ALPN
identifiers with an opaque blob of application parameters per
identifier, and when sent by the server is a single opaque blob of
application parameters for the application identified in the ALPN
extension.

Negotiating or advertising features is something multiple applications
will need to do and is not a feature specific to H3. Whatever we do in
H3 will likely be copied by other applications using QUIC. By
providing a general mechanism in QUIC transport, we provide
applications with a consistent way of achieving this goal. QUIC has a
design pattern of collapsing multiple layers into one to save on round
trips (e.g. combining crypto and transport handshake); this fits in
with that pattern.

Using application parameters for H3 SETTINGS clears up some issues. H3
doesn’t need to specify that an endpoint shouldn’t wait for its peer’s
SETTINGS since they’ve already arrived. Likewise, there is no
confusion about whether SETTINGS arriving after session tickets are
bound to the session tickets; SETTINGS arrives before the tickets and
the client doesn’t need to wait for the receipt of SETTINGS to bind
them to the ticket. It also simplifies the server binding SETTINGS to
the ticket since that is done as part of binding transport parameters
to the ticket.

This also provides opportunities for future features. Since the
exchange of SETTINGS occurs before application data, a new feature
doesn’t need to be specified in a way to provide an upgrade path from
“vanilla” H3 to something including this feature, and instead be
guaranteed that the new feature can be used for the entire connection.

Without application parameters, each application that needs to
advertise or negotiate application settings needs its own mechanism to
do so. This would result in multiple transport parameters or
extensions leading to duplication of work and layering violations.
Applications could instead exchange these settings in application
data, meaning that each application needs to define the semantics of
application data received before and after the settings have been
exchanged, as H3 currently does.

There is already a demonstrated need for an application parameters
mechanism in the QUIC handshake. One example is
https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 which is
currently using a “web_accepted_origins” transport parameter but could
easily use an application parameters mechanism instead.

I see two downsides to this proposal. The first is that the client’s
application parameters are sent in the clear. Application designers
will need to make a decision of how much they want to use this
functionality (they could limit what is sent by the client or only use
application parameters in the server direction). For H3, there are
only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_STREAMS,
and MAX_HEADER_LIST_SIZE, which do not reveal any information about
the user or the server they are connecting to and are likely constant
per H3 implementation.

The other downside is that if too much data is put in application
parameters, it could cause the number of packets for a client or
server’s flight to go from N to N+1, which would increase the chance
of head of line blocking.

Related issues:
https://github.com/quicwg/base-drafts/issues/2790: Binding settings
into session tickets
https://github.com/quicwg/base-drafts/issues/2945: When to send the
SETTINGS frame
https://github.com/quicwg/base-drafts/issues/2783: Consider making
SETTINGS part of the control stream header
https://github.com/quicwg/base-drafts/issues/436: Move SETTINGS into
TLS Handshake