Subject: QUIC Versions and Applications

From: Martin Duke <[email-masked]>
Date: Wed, 28 Apr 2021 08:54:16 -0700

Yesterday there was an interesting conversation on Slack, about whether h3
needed a new ALPN for QUICv2, that made me realize I had a very lazy mental
model where applications needn't worry about QUIC versions and QUIC
versions could be oblivious to what the app is doing. This isn't true at
all.

The basic dilemma here is that either

(1) applications need explicit updates when new QUIC versions roll out, if
for no other reason than to say that they are fully compatible. This would
make it hard to get rid of old QUIC versions, and slow deployment of new
ones, as some apps never change. Or

(2) Each QUIC version has to enumerate which applications work with it and
which don't, which seems... not scalable. Or

(3) There is a compatibility matrix with quic versions as rows and
applications and columns, and any time a spec adds a row or column it
should fill that row or column out completely. Or

(4) There are strict limits on future versions so that they don't take away
existing functionality (e.g. there MUST be an ability to get reliable
streams). or

(5) Applications MUST have application-layer fallbacks if some QUIC
features aren't available (the way MASQUE can use QUIC STREAM frames if
DATAGRAM isn't supported) - or maybe it can throw an application error

Maybe there's an alternative I can't see. The applicability draft
<https://www.ietf.org/archive/id/draft-ietf-quic-applicability-11.html#name-port-selection-and-applicat>
(currently in WGLC) says that each ALPN unambiguously defines the QUIC
version, which I guess is option (1).

There are second-order questions like: is this mediated through ALPN or
something else? But the first-order question is which layer has to manage
all this.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 28 Apr 2021 09:02:53 -0700

It's almost as if application-layer protocols need two version numbers,
one to indicate wire syntax and another to implement semantic capability over
time within a compatible syntax. I wonder where I've heard that before?

....Roy

> On Apr 28, 2021, at 8:54 AM, Martin Duke <[email-masked]> wrote:
> 
> Yesterday there was an interesting conversation on Slack, about whether h3 needed a new ALPN for QUICv2, that made me realize I had a very lazy mental model where applications needn't worry about QUIC versions and QUIC versions could be oblivious to what the app is doing. This isn't true at all.
> 
> (1) applications need explicit updates when new QUIC versions roll out, if for no other reason than to say that they are fully compatible. This would make it hard to get rid of old QUIC versions, and slow deployment of new ones, as some apps never change. Or
> 
> (2) Each QUIC version has to enumerate which applications work with it and which don't, which seems... not scalable. Or
> 
> (3) There is a compatibility matrix with quic versions as rows and applications and columns, and any time a spec adds a row or column it should fill that row or column out completely. Or
> 
> (4) There are strict limits on future versions so that they don't take away existing functionality (e.g. there MUST be an ability to get reliable streams). or
> 
> (5) Applications MUST have application-layer fallbacks if some QUIC features aren't available (the way MASQUE can use QUIC STREAM frames if DATAGRAM isn't supported) - or maybe it can throw an application error
> 
> Maybe there's an alternative I can't see. The applicability draft <https://www.ietf.org/archive/id/draft-ietf-quic-applicability-11.html#name-port-selection-and-applicat> (currently in WGLC) says that each ALPN unambiguously defines the QUIC version, which I guess is option (1).
> 
> There are second-order questions like: is this mediated through ALPN or something else? But the first-order question is which layer has to manage all this.
> 
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 28 Apr 2021 16:13:10 +0000

Yup. There is a potential combinatorial problem here when mapping to one number, especially with DATAGRAMS as they exist today where the semantics of the session aren’t apparent to any intermediary machinery.

I suppose the question is.. is this bad enough to require a statement of (a minimum of) two versions?

If option #1 implies incompatible apps, then.. things won’t work very well.

-=R

From: QUIC <[email-masked]> on behalf of "Roy T. Fielding" <[email-masked]>
Date: Wednesday, April 28, 2021 at 9:03 AM
To: Martin Duke <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: QUIC Versions and Applications

....Roy

On Apr 28, 2021, at 8:54 AM, Martin Duke <[email-masked]<mailto:[email-masked]>> wrote:

Maybe there's an alternative I can't see. The applicability draft<https://www.ietf.org/archive/id/draft-ietf-quic-applicability-11.html#name-port-selection-and-applicat> (currently in WGLC) says that each ALPN unambiguously defines the QUIC version, which I guess is option (1).