Re: New Version Notification for draft-duke-httpbis-quic-version-alt-svc-00.txt

On Wed, Mar 9, 2022 at 5:49 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:
...

> QUICvBOB could be accompanied by a document defining this split-stream
>> mapping for "h3" under the existing ALPN.  That's fine.  My point is,
>> nobody can resurrect the "h3" ALPN for QUICvBOB if "h3" wasn't initially
>> supported by QUICvBOB, so it would need a new ALPN value as you describe.
>>
>> My question is: is the QUIC WG willing to commit to this restriction?  If
>> the QUIC WG wants the ability to restore unsupported ALPNs for published
>> QUIC versions, that's possible, but it would require a different encoding
>> for QUIC version hints in Alt-Svc.
>>
>
> Speaking with no hats: that sounds like a dependency inversion to me. The
> QUIC WG is not the best venue for defining application protocols that use
> QUIC.
>

Agreed, that's not what I meant.


> DNS over QUIC is a good example: the work has been done in DRPIVE and they
> are responsible for defining their ALPN.
>

Sure.  QUICvBOB comes out, and then the DPRIVE working group says "great,
here's a draft showing how to do DoQ on QUICvBOB".  If we
publish draft-duke-httpbis-quic-version-alt-svc*, DPRIVE cannot use "doq"
as the ALPN for this, because "doq" predates QUICvBOB and QUICvBOB did not
support "doq" at inception.  Someone might already have deployed a server
that supports QUICv1 and QUICvBOB, and supports "doq" on QUICv1 but not on
QUICvBOB, because the latter combination was not  yet defined.

* and extend this logic to other discovery modes such as SVCB

The negotiation pattern implied by draft-duke-httpbis-quic-version-alt-svc
requires a restriction on how ALPNs and QUIC versions interact.  This
restriction is fine with me, but (1) I want to make sure it's fine with
QUIC WG, and (2) I think it should be written down somewhere.

So I would not expect a QUICvBOB document to make any commentary about
> application protocol specifics, especially not trying to port around
> mappings from version to version. That sounds like it could easily go awry
> and not fit the needs of the originators. Instead, I would expect QUICvBOB
> gets developed with a driving use case that probably occurs concurrently
> with another application mapping. Anything other application protocol that
> exists would then have to do its own analysis to decide if writing a new
> mapping is worth it.
>

In this sequencing, ALPN values will never be reused across QUIC versions,
so (paradoxically) there is no need for
draft-duke-httpbis-quic-version-alt-svc.

I would prefer a norm that new QUIC version drafts enumerate all the
pre-existing ALPNs that are supported, and new ALPN drafts enumerate all
the pre-existing QUIC versions that are supported.  (But we're on the wrong
mailing list for that discussion.)

...

> But what's needed I people understanding what features of the QUIC
>>> transport version they use, and what incompatible means.
>>>
>>
>> My point is that this understanding has to be frozen at the moment a QUIC
>> version is defined.
>>
>
> Coordination and phrasing is important here but I don't think we have
> enough experience to make firm recommendations quite yet.
>

I'm making a purely logical claim: if the client is only provided with
information about the server's supported ALPNs and QUIC versions
(independently), the QUIC handshake is only guaranteed to complete
successfully if the client and server agree on which ALPNs can be used on
which QUIC versions.  That means that this information cannot ever change
(unless _all_ servers can be updated before _any_ clients).