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

Hey Willy,

On Sat, 12 Mar 2022, 18:10 Willy Tarreau, <w@1wt.eu> wrote:

> On Sat, Mar 12, 2022 at 05:23:46PM +0000, Lucas Pardue wrote:
> > > Given that QUICvBOB wouldn't know "h3" ALPN by default, it would make
> > > sense to reuse the same ALPN precisely to indicate that it's exactly
> the
> > > same protocol but mapped differently (the mapping being dependent on
> the
> > > protocol stack).
> > >
> >
> > I don't agree with this position. We have come a long way in refining our
> > concepts and terminology of semantic HTTP and wire specific messaging.
>
> But note that what we usually call "wire" really has nothing to do with
> the wire but rather with the immediate next layer when going down the
> stack. Similarly H3 is not renamed when QUIC is transported over IPv6
> (or possibly even datagram UNIX sockets) and those are different
> "on-wire" representations as well.
>
> If the next version of QUIC is incompatible with V1 (say different
> packet format) but provides similar streams, there's no reason why H3
> would have to be mapped differently and it will certainly remain H3. But
> then if more substantial changes happen, for example let's say that like
> in H2, QUICvBOB starts to expose the stream number as a preambule of the
> stream frames, and that nothing else changes, it's perfectly possible
> that we'll just see an updated RFC saying "H3 frames are prefixed with a
> 32-bit stream ID when mapped on QUICvBOB and for the rest, please refer
> to RFCxxxx".
>

Right now, QUIC stream abstractions are available for applications to use.
It doesn't really matter so much how streams are framed or packetized. If
something changes the abstraction in a way that requires a change in the
application mapping, that sounds like a breaking change.


> And after all there's HTTP/0.9 on top of QUIC which wasn't renamed 2.9
> or stuff like that.
>

That's not a formally standardised protocol, it was used mainly for interop
in the early days with success, and continues to drive transport oriented
testing in e.g. the interop runner. But it does use QUIC streams according
to the abstraction that v1 provides. Because the streams themselves and the
bytes-on-stream format have special meaning it is indeed an application
mapping and it has a few ALPNs "hq", "hq-interop" that help endpoints
figure out what they are doing.

Maybe we could take a leaf put of user,agent strings and call it "hq (like
HTTP/0.9)" :-)


> I think it's important to plan for the possibility to have to rename
> the protocol if it's not possible to map it (or if it doesn't make
> sense for efficiency reasons), but I don't think we'd need to make this
> mandatory at all.
>

Totally agreed! Apologies if it appeared i was making blanket statements
about the future.

ALPN tokens are not the easiest wat to articulate the nuances that we have.
The application protocol is HTTP, yet we use ALPN to describe the
intermediate representation in between. It's a sticky situation. We will
have to consider these questions as the transport layer changes and make
our best determination at the time.

This is also part of why I think asking QUIC WG to make judgement calls
about how future versions will affect applications is a bit futile. They
should inform but not dictate.

Cheers
Lucas