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

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Oct 2019 13:50:24 -0700

Does this need to be a 1.0 feature?

On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie <[email-masked]> 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=
> [email-masked]> 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
>>
>>

---

From: Nick Harper <[email-masked]>
Date: Tue, 1 Oct 2019 16:41:36 -0700

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 <[email-masked]> wrote:
>> 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=[email-masked]> wrote:
>>>

---

From: David Schinazi <[email-masked]>
Date: Tue, 1 Oct 2019 17:20:48 -0700

Additionally, the current status quo makes it hard to have SETTINGS
play nicely with 0-RTT. Fixing this is important to deploying IETF QUIC.
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=
[email-masked]> wrote:

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 1 Oct 2019 17:55:05 -0700

Hi Nick,

On Tue, Oct 1, 2019 at 4:41 PM Nick Harper <[email-masked]> wrote:

> There is no doubt there is a tension here, but if you look at our original
milestones (https://datatracker.ietf.org/wg/quic/history/) we are more than
somewhat late.  Having just sent one "Late, great WG name" message, I'm
probably a bit more sensitive to this than most, but I strongly believe
that getting QUIC v1 out there and getting field experience now is the best
choice for the moment.    This is a major design issue, and it is coming
late when we are trying to raise the bar on change.

If we didn't have a workable solution at all, this would be something that
was clearly needed.  But the current approach does work and has understood
privacy properties. As I said, other applications may need substantially
different things than H2 and getting something of sufficient generality
will take time.  The other option, specifying so its suits only H2 well is
the other side of the risk you have above, and I believe it is a serious
risk.

Architectural purity is on your side, so I don't think you're wrong to want
this.  But I think it may be a want, not a need, at this point.  And that
is why my answer sides with Roberto.

Just my personal opinion,

Ted

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 2 Oct 2019 10:23:03 +0900

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

> On Tue, Oct 1, 2019 at 4:41 PM Nick Harper <nharper=[email-masked]> wrote:
>>

-- 
Kazuho Oku

---

From: David Schinazi <[email-masked]>
Date: Wed, 2 Oct 2019 14:20:52 -0700

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.

On Tue, Oct 1, 2019 at 6:23 PM Kazuho Oku <[email-masked]> wrote:

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 3 Oct 2019 08:49:49 +0900

2019年10月3日(木) 6:21 David Schinazi <[email-masked]>:
>
> If we decide that the first requests need to operate without knowledge of settings,
> 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,

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.

-- 
Kazuho Oku

---

From: Nick Harper <[email-masked]>
Date: Thu, 10 Oct 2019 14:52:14 -0700

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 <[email-masked]> wrote:

> >> >> >> 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:
> >> >> >>
> >> >> >> 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.
> >> >> >>
> >> >> >>> extensions leading to duplication of work and layering
> violations..

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 17 Oct 2019 10:44:07 -0400

On Wed, Oct 02, 2019 at 02:20:52PM -0700, David Schinazi wrote:
> 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.

Is there prior art?  That is, are there protocols that allow extension
settings to be specified in a first request/packet?

  - Dmitri.

---

From: David Schinazi <[email-masked]>
Date: Thu, 17 Oct 2019 08:53:12 -0700

> settings to be specified in a first request/packet?

TLS has client hello extensions. TCP has options that can travel with the
SYN.