Subject: [quicwg/base-drafts] QUIC/ALPN Version Specific Transport Parameters (#3965)

From: Nick Banks <[email-masked]>
Date: Tue, 28 Jul 2020 08:08:33 -0700

## Problem

Currently when a client offers multiple ALPNs when connecting to a QUIC server, it still only offers a single QUIC transport parameters set. This implicitly requires (assumes?) that the single TP set is (must be) valid for every protocol version offered. The same is true for QUIC versions when version negotiation is added.

## Possible Solution

IMO, we should allow for the client to offer different settings for different QUIC version or ALPNs (or the corresponding combinations?). If we made a change here, I'd also prefer the solution to **not be dependent on any further TLS changes**, as this would make the solution much more disruptive. It has been suggested on Slack that the ALPS TLS extension might be good for this, but IMO, the fact that it would require TLS changes is a non-starter for QUIC v1.

One possible solution for fixing this is to modify the format of the existing TPs to a list of { quic_version, alpn, TPs }, and allow for quic_version to be zero and/or alpn to be empty to indicate unrestricted applicability of these TPs (to all versions/ALPNs).

## Specific Examples of Problem

- App protocol v1 does not allow server initiated bidi-streams, and explicitly an error to set an initial stream count greater than zero. App protocol v2 now has a use for these streams and requires the client to send a count greater than zero.

- A server supports two related protocols, P1 and P2, but each protocol has a slight different interpretation of unidirectional streams, and require different initial counts to be set.

- QUIC version 2 wishes to remove or redefine a particular transport parameter.

## Why Should this be in Version 1?

If we don't take a change/fix for this in version 1, it restricts the kinds of changes to TPs we can make in future QUIC versions.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965

---

From: David Schinazi <[email-masked]>
Date: Tue, 28 Jul 2020 08:48:07 -0700

I don't think we should make this change at this point.

Regarding separate ALPNs over QUICv1, we can solve this by saying that protocols running over QUIC MUST NOT enforce maximum values for transport parameters. For example HTTP/3 does not use server-initiated bidirectional streams, but there is absolutely no reason for HTTP/3 to require the corresponding transport parameter to be zero.

Regarding multiple QUIC versions, I don't understand the problem. The packet containing the transport parameters is a long header that carries the QUIC version, so endpoints just need to interpret transport parameters based on the QUIC version they were sent in.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665119180

---

From: mjoras <[email-masked]>
Date: Tue, 28 Jul 2020 08:53:02 -0700

I agree with @DavidSchinazi. I'm not in love with the current transport parameters, but I don't see an abundant reason to change them at this point. I similarly don't think they are actually that coupled to TLS or the QUIC version. As David notes, the interpretation is inherently QUIC-version dependent.

We could, for example, completely ditch transport parameters in the TLS extension for QUIC v2 and instead opt for a TransportSettings frame.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665122044

---

From: Nick Banks <[email-masked]>
Date: Tue, 28 Jul 2020 08:53:22 -0700

For the multiple QUIC versions, my understanding of the direction of version negotiation was that the client would use one version, but include the list of supported versions in its TPs. Then the server could negotiate that to a different QUIC version than the one used in the client initial packet. In that scenario, it would require the TP set to be valid for all versions that the server could negotiate to.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665122236

---

From: Nick Banks <[email-masked]>
Date: Tue, 28 Jul 2020 15:56:50 +0000 (UTC)

@mjoras I agree there are other possible solutions for version 2, but as you point out, they likely require a TLS stack change, which I am trying to avoid.

I guess this could all be pushed to an extension as well. A new transport parameter that encodes the list of version/ALPN specific parameters... I just don't know how you'd handle the extension being optional.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665124218

---

From: Nick Banks <[email-masked]>
Date: Tue, 28 Jul 2020 08:59:55 -0700

Also, I still don't have a solution for the "related protocol" example above without adding extra cross-protocol negotiation logic, where the server app knows that the client was offering P1 and P2, and therefore understands how to consume the "combined" TP set in a protocol specific way. OR, I'd have to completely merge the protocols and do the negotiation at the app layer.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665125954

---

From: David Schinazi <[email-masked]>
Date: Tue, 28 Jul 2020 09:09:18 -0700

@nibanks it sounds like you're referring to [compatible version negotiation](https://tools.ietf.org/html/draft-ietf-quic-version-negotiation-00#section-7), but I don't think your understanding is correct. In that scenario, the client sends a QUICv1 Initial/ClientHello, and then the server can reply with a QUICv2 Initial/ServerHello. That doesn't require the transport parameter meaning to be the same, the server just needs to know that it's using the v1 interpretation, and the client needs to use the v2 interpretation.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665131236

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 28 Jul 2020 09:10:55 -0700

I agree to what @DavidSchinazi and @mjoras say. In addition to what they have stated, I'd point out that endpoints can loosen the settings by sending frames after the handshake is complete.

Most transport parameters are merely used to communicate the initial values. And for other parameters that communicate the final value (e.g., max_ack_delay), we can add frames for changing the behavior as we find out the needs.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665132085

---

From: Nick Banks <[email-masked]>
Date: Tue, 28 Jul 2020 09:32:46 -0700

@DavidSchinazi I guess my line of thinking was that instead of just sending v1 (and indicating support for v2) and the server deciding how to migrate the v1 TPs to v2, the client would be able to send both v1 and v2 TPs (or v1 plus whatever extra v2 requires). Then the server doesn't have to migrate the TPs at all. This might even allow for a greater range of compatible versions. Without this, v1 and v2 could be incompatible because of a change in how a TP is used.

I guess if we wanted to go that route, the different TPs could be part of the version negotiation extension draft.

@kazuho applications can theoretically decide how to interpret an initial TP value however it wants. Not allowing for the app to pick different initial values based on the protocol version being used restricts. If that's the direction folks want to go, we should probably at least mention this so that protocols take this into account when designing their v1, so they don't back themselves into a corner.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665143494

---

From: David Schinazi <[email-masked]>
Date: Tue, 28 Jul 2020 17:24:32 +0000 (UTC)

Adding some editorial changes to QUICv1 to reflect this discussion sounds like a fine resolution to me

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665160029

---

From: ianswett <[email-masked]>
Date: Tue, 28 Jul 2020 10:43:00 -0700

This reminds me of the conversation about putting SETTINGS into TP, which prompted the creation of the ALPS proposal.

I'd like to see a future version of QUIC do a better job with both TPs and application settings, but it's way too late to be making such a substantial change to QUIC v1 at this point.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665179782

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 28 Jul 2020 11:38:03 -0700

If someone wants to propose an editorial PR we can consider it as an editorial issue. Failing that I sense we can live with the document as is.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665208597

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Jul 2020 20:30:58 -0700

I'm not seeing an action for me in this discussion.  I will of course review any PR that someone proposes, but it seems like the minefield is sufficiently well mapped out already.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665410077

---

From: Nick Banks <[email-masked]>
Date: Wed, 29 Jul 2020 04:06:18 -0700

I'll look into adding some warning text later today.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665599337

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Jul 2020 04:47:54 -0700

Discussed at IETF 108. Proposed resolution are editorial changes.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#issuecomment-665617277

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 31 Jul 2020 12:35:20 -0700

Closed #3965 via #3973.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3965#event-3609976945