Re: QMux outcomes from IETF 125

[Kazuho Oku <[e-mail]>]

2026年3月26日(木) 15:44 Martin Thomson <[e-mail]>:

> On Thu, Mar 26, 2026, at 16:26, Kazuho Oku wrote:
> > Without a record layer, the equivalent constraint would be to say that
> > the maximum size of a STREAM frame, including its frame header, is
> > 16384 bytes.
>
> That seems like a reasonable implementation strategy.  I wouldn't mandate
> it in the protocol though.
>
> > That is what I am trying to point out. The record-based approach does
> > not require changes to frame decoders, and it works regardless of the
> > type and number of QUIC frames the sender chooses to send.
>
> Yes, the record layer makes it easier to implement.  My point is that it
> in doing so it encourages a poor implementation.
>
> > and provides a weaker mechanism for aligning STREAM frame boundaries
> > with TLS record boundaries.
>
> I *think* that I understand your argument, but it wasn't obvious.  Are you
> saying that non-STREAM frames will be added to TLS records in ways that the
> entity that generates STREAM frames might be unaware of, causing the STREAM
> frame to overflow the TLS record?  Can't you have a layer that tracks bytes
> written so that it never lets a STREAM frame span a TLS record if you cared
> about that?
>
> Of course, I don't think you should care about that.  My view there is
> that you can decode (and deliver!) the first half of a STREAM frame that is
> split between TLS records.  It requires incremental decoding of frames, but
> I've been arguing that this is what you want anyway.
>
> > All that said, I think part of the difficulty here is that we do not
> > have a concrete counter-proposal to QMux records.
>
> I thought that "don't change the draft" was the counter-proposal.  That's
> what I've been advocating for.  (I apologize for maybe not being clear
> about that.)
>

Thanks, I think we are on the same page regarding how QMux records work,
even though we might disagree on how effective they are in keeping frames
and records aligned.

However, I am uncertain if "don't change the draft" is the correct position
to take if the concern is to encourage incremental decoding.

As -00 stands today:
* the payload of a STREAM frame MUST be no larger than 16,384 bytes, unless
extended by transport parameter;
* if the Length field of a STREAM frame is omitted, the frame extends to
the maximum size.

This feels to me like the worst of both worlds:
1. The maximum frame size is small enough that implementations might choose
to wait for complete frames.
2. The design naturally leads to STREAM frames being split across multiple
TLS records, because the maximum size of a STREAM frame including the frame
header is slightly larger than what one TLS record can contain. This
induces buffering in receivers waiting for complete frames.
3. It still requires receivers to modify their frame decoding strategy from
QUIC v1 to handle  partially received frames gracefully.

Compared to such a design, QMux records seem better to me, because they fix
(3) and  mitigate (2).

Instead, if *your* goal is to encourage incremental decoding, I think a
design like H3 frames, with no limit on the maximum frame length, might be
a better fit than -00.

WDYT?

-- 
Kazuho Oku