Re: ALPN and QUIC versions

[Ian Swett <[e-mail]>]

I do think this is worth discussing(again) now that we're about to ship the
first application on top of QUICv1 as well as the applicability drafts.  We
don't have a ton of time to make adjustments, but maybe enough time.

I think Lucas' thinking is heading in a good direction.  My mental model is
that new versions could declare if they offer the featureset of another
version.  So I can mint a bespoke version of QUIC and as long as it
supports the v1 featureset, it'll use the same ALPN.  Could a version of
QUIC specify that it supports the features of multiple versions(ie: a
version of QUIC like v1 and one that only supports datagrams)?

Having every application or extension specify which features it's dependent
upon sounds a bit problematic in practice to me, but maybe it's not so bad.

There are lots of workable ways to do this, but minting a new alpn for
every transport version does seem a bit excessive unless we're not going to
have many transport versions.

Ian

On Wed, May 19, 2021 at 8:09 PM Lucas Pardue <[e-mail]>
wrote:

> Hi Martin
>
> Speaking as an individual. There's a lot to consider here, I don't have a
> complete response.
>
> For a start, I think there are ways to rephrase the applicability draft
> text to get over some thorniness - seems I'm on the hook to do that,
> reviews will will welcome.
>
> To respond to one of your suggestions
>
>
> On Wed, 19 May 2021, 16:27 Martin Duke, <[e-mail]> wrote:
>
>>
>> 4) There is no formal trail of linkages. New version RFCs should say what
>> apps they support (possibly as generic as "all v1 applications work with
>> the new version") and applications should say if (a) the list of usable
>> versions is other than the full known set and (b) what properties it needs
>> from a QUIC version to operate. This is the path I took in a v2 PR
>> <https://github.com/martinduke/draft-duke-quic-v2/pull/6> [3], which has
>> no official standing whatsoever. This makes the forensics to obtain the
>> full list of usable versions quite a bit harder, but won't explode the ALPN
>> registry or the front page of HTTP/3.
>>
>
> I might grade incompatible breaking versions on at least two criteria.
> First, is the wire image the same? Second, are the protocol feature changes
> that break the contract with upper layers, which would cover removing
> features, changing features in ways that break dependent behaviour, adding
> features that break dependent behaviour.
>
> Such a grading exercise would appear to be a useful function of the QUIC
> WG in the long run. What I mean by this is that (hypothetically) we should
> encourage versions to state if their compatibility with other versions is
> breaking or non-breaking. The QUIC version IANA table could, for example,
> codify some of this.
> The group has the expertise to assess such claims and the desire to avoid
> version relationship explosion in breadth or depth (I.e. we would heavily
> normalize).
>
> QUIC extensions could state the known (at the time of writing) version(s)
> that they extend. To keep it simple, they'd just need to state the earliest
> registered version on each breaking version. We assume that non-breaking
> versions published by the IETF all work. A single QUIC extension document
> can define how it extends several breaking QUIC versions. We have a similar
> situation right now when defining logically equivalent behavioral
> extensions that need to work over H1, H2 and H3.
>
> Application protocols could also state known (at the time of writing)
> version(s) that they run over. Same as above.
>
> When future breaking QUIC versions are published, extension and
> application protocols can respond. Update documents could be effectively
> no-op, require major/minor surgery, or state explicitly that a version is
> not supported if they help the strong need to.
> To make this activity easier, both extensions and application protocols
> (and their extensions!) would benefit from stating the QUIC protocol
> features that they depend on. Reviewing those statements is likely a
> service the QUIC WG should provide to other groups.
>
> I think this possibly leads to a hybrid option 4, where the ALPN registry
> has a column that lists only breaking QUIC versions. And we don't mandate
> any rules on the number of versions that a token can relate to.
>
> Cheers
> Lucas
>