Re: [External?] Re: Unbound DATA frames in HTTP/3 proposal

On Sat, Oct 11, 2025 at 03:30:39PM -0400, Demi Marie Obenour wrote:
> On 10/11/25 02:01, Willy Tarreau wrote:
> > On Fri, Oct 10, 2025 at 09:01:36AM +0900, Kazuho Oku wrote:
> >> Consider the case of sending 10 bytes. The composition of a UDP datagram
> >> *near minimum* is like:
> >>
> >> QUIC 1st byte: 1
> >> QUIC DCID: 0
> >> QUIC packet number: 2
> >> QUIC STREAM frame header: 1 /* type */ + 2 /* id */ + 2 /* offset */ = 5
> >> H3 DATA frame header: 1 /* type */ + 2 /* length */ = 3
> >> H3 DATA frame payload: 10
> >> QUIC AEAD tag: 16
> >>
> >> So, in the case of this example, total size of the UDP datagram is 37
> >> bytes, and the H3 DATA frame header takes 3 bytes; i.e., 8%.
> >>
> >> And we aren't even talking about the IP header.
> > 
> > And potential ACKs in return!
> > 
> >> Or, maybe the H3 layer (and also the QUIC layer) should provide support for
> >> message-oriented streams like SCTP does, so that multiple protocols built
> >> on top can benefit from them.
> > 
> > That's why I suggested that I think we're missing an equivalent of the
> > H1 upgade. In H2 and H3 we seem to be focusing a bit too much on
> > encapsulation, which requires to fill all intermediate layers, while
> > at least H3 is linear over a single stream and could very well benefit
> > from a protocol upgrade, to switch to something that is transported over
> > a bare QUIC stream. This would seem much cleaner to me, given that in
> > the proposal here there's no intent to switch back to H3 after the
> > transfer (even trailers are impossible).
> > 
> > At least this would ease (and possibly standardize) the transition of
> > H3-to-anything over QUIC. And the "message-oriented streams" you're
> > mentioning could be the first one.
> 
> I have two concerns about this:
> 
> 1. It might require an extra round-trip.
> 2. It might not support the use-case of optimizing pure H3.
> 
> The first can be addressed by a "mandatory upgrade" mechanism.
> This means that subsequent data on the stream will use the new
> protocol, and if the server rejects the upgrade it must close
> the stream without interpreting it.  The second can be addressed
> by allowing an "upgrade" to a raw H3 message body.

We already have this, it's RFC9220 which ports RFC8441 to H3. However
my understanding is that it still relies on regular H3 DATA frames,
while here we'd like to pass infinite data over the QUIC stream, maybe
it could be a new variant to that extension.

My understanding of the currently discussed proposal is to say "past
these headers, these are only opaque data", which is why I think it
translates the intent to switch to another protocol, which precisely
is the case where doing multiple encapsulations becomes complex in
terms of implementation. But if we can say "over this stream, past
these headers, these are only opaque bytes", then it should be fine
as well, and possibly be transported over RFC9220-only agents when
the extension is not supported.

> Ideally, this could be established at QUIC/TLS connection time,
> so that the very first H3 request could use this.

There are many ways to advertise support for extensions including the
currently discussed one, IMHO this is not a concern at this point.

Willy

Received on Sunday, 12 October 2025 07:32:02 UTC