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

[Nick Harper <[e-mail]>]

I filed https://github.com/quicwg/base-drafts/issues/3086 for this issue
and so we can discuss it next week in Cupertino.

On Wed, Oct 2, 2019 at 4:50 PM Kazuho Oku <[e-mail]> wrote:

> 2019年10月3日(木) 6:21 David Schinazi <[e-mail]>:
> >
> > If we decide that the first requests need to operate without knowledge
> of settings,
> > we're effectively crippling the main extension mechanism we have in
> HTTP/3.
> > I'm not comfortable saying that for the entire lifetime of QUICv1 we
> cannot have
> > extensions that impact the first requests. That feels like painting
> ourselves into a corner.
> >
> > There are many features that we can punt out of QUICv1 and figure out
> later as extensions,
> > but it's critical that we build an extension mechanism that allows that.
>
> For HTTP/3, I think that we'd likely be fine with not having settings
> delivered before issuing requests. That's how HTTP/2 has been, and we
> are used to dealing with that. Though admittedly, QPACK is more
> disciplined on what can be done in such case compared to HPACK.
>
> Other application protocols using QUIC v1 can define their own TP, if
> having settings exchanged before 1-RTT data becomes a critical issue
> for them.
>
> >
> > On Tue, Oct 1, 2019 at 6:23 PM Kazuho Oku <[e-mail]> wrote:
> >>
> >> 2019年10月2日(水) 9:21 David Schinazi <[e-mail]>:
> >> >
> >> > Additionally, the current status quo makes it hard to have SETTINGS
> >> > play nicely with 0-RTT. Fixing this is important to deploying IETF
> QUIC.
> >>
> >> While I understand and share the pain, I am not sure if this should be
> >> a blocker for QUIC v1, as 0-RTT is essentially a must-implement for
> >> HTTP/3 (the primary application protocol for QUIC v1).
> >>
> >> 0-RTT requires clients (and servers) to operate without the knowledge
> >> of the settings that are sent by the server. Until the client receives
> >> the settings of the server and switches to using 1-RTT packets, the
> >> client is expected to use the settings of the previous connection. The
> >> server is expected to accept 0-RTT only if it knows that the settings
> >> parameters of that the client is using for 0-RTT.
> >>
> >> Assuming that we cannot remove this requirement, I do not think it's
> >> too complicated to require endpoints when using 1-RTT to operate
> >> without the knowledge of settings (i.e. operate with a very
> >> conservative set of properties) until it receives the settings from
> >> the peer.
> >>
> >> > We're chartered to produce a protocol with fast connection
> establishment,
> >> > and if we fail to negotiate options and extensions nicely with that,
> we'll
> >> > harm extensibility long-term and cause deployment of damaging
> workarounds.
> >> >
> >> > David
> >> >
> >> > On Tue, Oct 1, 2019 at 4:41 PM Nick Harper <nharper=
> [e-mail]> wrote:
> >> >>
> >> >> I think it loses most of its utility if it's not a v1 feature. The
> >> >> main motivation for the feature is to simplify application protocols.
> >> >> At the time that v2 is introduced and application protocols are being
> >> >> specified to use it, existing application protocols will already have
> >> >> an application-specific way to negotiate params, so they will
> continue
> >> >> to use that instead of using both the existing application-specific
> >> >> mechanism (for v1) and v2-only application parameters feature (for
> >> >> v2+). (I'm assuming that as applications switch from using QUIC v1 to
> >> >> QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3,
> instead
> >> >> of like upgrading H2 to H3.)
> >> >>
> >> >> On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla <[e-mail]> wrote:
> >> >> >
> >> >> > Does this need to be a 1.0 feature?
> >> >> >
> >> >> > On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie <[e-mail]>
> wrote:
> >> >> >>
> >> >> >> 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
> >> >> >>>
> >> >>
> >>
> >>
> >> --
> >> Kazuho Oku
>
>
>
> --
> Kazuho Oku
>