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

Hey Willy,

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

> Hi Lucas,
>
> On Thu, Mar 10, 2022 at 04:08:48AM +0000, Lucas Pardue wrote:
> > 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.
>
> I disagree with this. The upper-level protocol indeed defines a mapping,
> but that mapping is not exclusive. We didn't rename HTTP/1.1 to 1.2 when
> its mapping over TLS was clarified for example. Instead a new RFC would
> be emitted to explain how to map H3 to QUICvBOB. This is far more desirable
> because it allows preservation of all the protocol details from end to end
> when only the mapping changes. Imagine for example a QUICv1 to QUICvBOB
> gateway. It would only have to deal with the change of mapping but does
> not need to redefine a new protocol. Encoding, flow control, compression
> etc wouldn't need to change. I the worst case an updated protocol spec
> would be emitted, listing the various known mappings, and would take
> that opportunity to fix errata and that would be all.
>
> 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. I'm
very excited for when we get all the HTTP RFCs published soon and we have a
consistent set of documents.

Before ALPN we had schemes and port numbers. Those things have become moot,
we will likely always expect semantic HTTP over QUIC to use https and be on
UDP 443. Having a way to signal the mapping onto a specific version is
important. We started out calling it HTTP/2 over QUIC but that was
confusing. I think it might be similarly confusing HTTP/3 over QUICvBOB,
rather than just HTTP/4 (this speaks to Amos' reply  elsewhere).

I think domenof how this will play put will depend exactly on what change
future QUIC versions bring. I think most forms of change will turn out to
be completely invisible to applications and they can live without the
worry. What I mean by this is changes that affect transport behaviour or
performance can affect applications but the API presented to the
application layer (connection lifetime, reliable streams lifetime) is
untouched.

Cheers
Lucas


> > 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.
>
> Indeed ;-)
>
> Willy
>