Re: QMux outcomes from IETF 125

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