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

On Thu, Mar 10, 2022 at 2:30 AM Ben Schwartz <bemasc@google.com> wrote:

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

The model I have, and others might disagree  (and which might not be
expressed well in the draft and as such we'd need to address), is that
these version hints are for compatible versions of QUIC related to the
Alt-Svc entry that has a single ALPN. For example, QUIC v1 and v2 are
compatible and as far as the H3 mapping is concerned, identical. The
example given in the spec is

Alt-Svc: h3=":443"; quicv="709a50c4,1"

If we publish QUICvBOB and it is incompatible, then H3 on QUICvBOB IMO
needs new application mapping and a new ALPN. For example "h3bob". Trying
to overload ALPN IDs for all version of QUIC whatever might come is
dangerous. On the other side of the coin, defining new ALPNs for *every*
variant of a QUIC version is a great way to DoS the IETF and IANA
processes.

In this scenario, if we defined QUICvBOBthesecond, as compatible with
QUICvBOB but incompatible with QUIC v1 and v2, then I might expect an
Alt-svc like

Alt-Svc: h3bob=":443"; quicv="b0b2,b0b1", h3=":443"; quicv="709a50c4,1"


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

That seems an intrinsic quality of declaring a version to be compatible
with another QUIC version. Listing things out doesn't seem useful in a QUIC
version document itself. New ALPN drafts are really the application mapping
documents I mentioned, there it does seem more useful to declare a set of
incompatible versions of QUIC that are known to be explicitly targeted by
the mapping.

There is value in the IETF community coordinating on these things, we
should try to make affordances for that. But the QUIC WG is not best placed
to run continued analysis on application protocols that it didn't develop
and doesn't maintain.

Cheers
Lucas