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

[Ted Hardie <[e-mail]>]

Hi Nick,

Two points in addition to the privacy issue already raised make me concur
with Roberto that this should be v2 or later.  The first is this:

"Negotiating or advertising features is something multiple applicationswill
need to do and is not a feature specific to H3."

Absolutely true, but there is also a fairly large variability in how
applications do this.  If we design something now that works for H3, it may
very well be sub-optimal or useless for later application targets.  Getting
something general enough to handle DNS, WEBRTC,  SMTP, plus the various
flavors of IoT protocols I've heard as targets hoping to move to QUIC is
going to take time and care, and it will block completion of v1.

The second is this:

*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.

Depending on what counts as application parameters, this could be more than
N+1.  Someone running NETCONF over QUIC, for example, would be using a
fairly verbose syntax in which each parameter is a full URN.

regards,

Ted Hardie


On Thu, Sep 26, 2019 at 5:52 PM Nick Harper <nharper=
[e-mail]> wrote:

> 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
>
>