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

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

> Hi Ben
>
>
>
>
> On Wed, 9 Mar 2022, 19:44 Ben Schwartz, <bemasc@google.com> wrote:
>
>> I would like to see this draft define a matching SVCB parameter as well.
>>
>
> A matching SVCB parameter sounds like a sensible design choice. From a
> process perspective is HTTP WG a suitable venue to pursue that?
>

I'm not a relevant WG chair but it seems fine to me, subject to DNSOP
cross-review.

This draft seems to be predicated on several assumptions about QUIC
>> versioning:
>> * The QUIC handshake will always be downgrade-resistant.
>> * There will soon be QUIC versions whose Initial cannot be parsed as
>> QUICv1.
>> * After a QUIC version is defined, it will never gain support for an ALPN
>> that predates it.  (Otherwise, the client and server might disagree on
>> whether QUICvN supports the given ALPN.)  In principle, this requires that
>> definitions of new QUIC versions and new ALPNs do not occur concurrently.
>>
>> Does the QUIC WG have consensus on these points?
>>
>
> Your two first points seem accurate, although I'll defer to the VN experts
> in the room to state definitively.
>
> On the third point I'm not sure I follow what you are saying. Imagine a
> QUIC version ("bob") was defined that was incompatible with QUIC v1. Let's
> say it removed client-initiated bidirectional streams. The "bob" version
> can't support the predated "h3" ALPN because the HTTP/3 mapping onto QUIC
> would be broken. Somebody could define a new mapping that used a pair of
> uni streams for request and response, that mapping would need a different
> ALPn value than "h3".
>

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.


> In such a scenario don't think there is a hard requirement on concurrent
> definitions.
>

If Alice is writing a draft defining the "alice" ALPN, and Bob is writing a
draft defining QUICvBOB, it needs to be unambiguous whether they are
compatible.  If the drafts are racing, things could get confusing if either
says "supports all versions of QUIC" or "supports all QUICv1 ALPNs" or
similar.

I'm not actually worried about this.

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.