Re: ALPN and QUIC versions

[David Schinazi <[e-mail]>]

Hi ALPN enthusiasts,

Since we've made some good progress on QUICv2, I think it's
time to reopen this thread - so I've opened a GitHub issue for it:
https://github.com/quicwg/quic-v2/issues/30
In a nutshell, if we don't do anything there won't be a way to
deploy QUICv2 without QUICv1 support, and I think we should
make that decision consciously. Please send thoughts on the issue.

Thanks,
David

On Fri, Jun 4, 2021 at 11:49 AM Ian Swett <ianswett=
[e-mail]> wrote:

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