W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2022

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

From: Willy Tarreau <w@1wt.eu>
Date: Sun, 13 Mar 2022 06:04:39 +0100
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Ben Schwartz <bemasc@google.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Duke <martin.h.duke@gmail.com>
Message-ID: <20220313050439.GC1409@1wt.eu>
Hi Lucas,

On Sat, Mar 12, 2022 at 07:05:58PM +0000, Lucas Pardue wrote:
> > 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.

Yes seen like this I agree. I mean that there's always one form of
encapsulation or representation for a protocol to be carried inside
another (except when dealing with purely infinite byte streams), and
that often the adaptations required when the lower one changes can be
seen as part of the mapping that comes from the new one.

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

OK then I think we're on the same line and possibly you're thinking
about more breaking changes than I was envisioning, which is why we both
have different appreciations on this.

> Apologies if it appeared i was making blanket statements about the future.

No need to apologize :-)

> ALPN tokens are not the easiest wat to articulate the nuances that we have.

Indeed! It's even more difficult in QUIC because there's one extra layer
that was not visible before and it's easy to make the confusion between
each layer and their respective mapping. Even in haproxy we made the
mistake, the other day I noticed "proto quic" on a "bind" line, and I
said the guys "it should be h3 here, not quic since that's the same
name as the one that comes from ALPN", and they said "hmmm indeed you're
right" :-)

> The application protocol is HTTP, yet we use ALPN to describe the
> intermediate representation in between.

It's not "just" HTTP because with different versions come different
possibilities even at the application level. For example, HTTP/1.1
brought 100-continue and new methods, H2 brought push and initially
lost websocket (before 8441), etc. Thus the application layer is
interested by the version, and the version is not simply a matter of
mapping to a transport layer, even if we all know that usually they
come together.

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

Most likely yes. And I'm pretty sure we'll see H4 on top of the next QUIC
anyway because we'll want to address newly discovered shortcomings in an
incompatible way.

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

I agree. Eventhough I'm a low-level networking guy, I'm well aware that
lower layers are here to serve the upper ones, not the opposite.
Limitations and suggestions ought to be communicated upstream but that's
all.

Willy
Received on Sunday, 13 March 2022 05:04:57 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 13 March 2022 05:04:59 UTC