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

Hi Ben,

On Wed, Mar 9, 2022 at 8:19 PM Ben Schwartz <bemasc@google.com> wrote:

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

That makes sense to me.


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

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. HTTP/3 is a notable exception, a shared responsibility between QUIC
and HTTP WGs that made sense while QUIC v1 and HTTP/3 were being developed
in tandem. HTTP/3 ownership is now back in HTTP WG hands. I would expect
future application mappings for QUIC to be defined in the most suitable
WG*. DNS over QUIC is a good example: the work has been done in DRPIVE and
they are responsible for defining their ALPN.

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

Coordination and phrasing is important here but I don't think we have
enough experience to make firm recommendations quite yet.

An "alice" ALPN doesn't represent an abstract concept, it is a real
bytes-on-the-wire and transport state dependent machination. I would
generally discourage anyone making a statement like "application mapping
$foo works for for all versions of QUIC" because that is easily
falsifiable.". Instead something like "this mapping is defined for QUIC v1,
and it is expected to work with other QUIC versions that are compatible
with v1" is more likely to hold true. Since the mapping _has_ to describe
how transport features are used, it doesn't seem too hard to predict what
would be incompatible. However, that depends on definitions of compatible
or incompatible to some extent.

Cheers,
Lucas