2026年3月26日(木) 13:14 Martin Thomson <[email protected]>: > > > On Wed, Mar 25, 2026, at 15:04, Kazuho Oku wrote: > >> In that case, if you have a 1:1:1:1 write:frame:QMux record:TLS record > ratio, there is zero difference between the options. > > > > I disagree, unless you are proposing to impose a size limit on the > > entire encoded STREAM frame, including the frame header bytes, which > > would be an exotic design compared to having a size limit on the STREAM > > frame payload. > > I don't follow your argument. I thought we'd agreed that writing a single > STREAM frame produced identical bytes in the record or no record design, > unless you are right at the boundaries where the varint encoding for the > record is larger than the varint encoding for a STREAM frame length.
They produce identical lengths only when identical constraints are applied. The key question, though, is how to define the constraint so that QUIC frame boundaries, and also QMux record boundaries, align with TLS record boundaries. With QMux records, that constraint is straightforward: the maximum record size is 16384 bytes. That naturally leads to carrying at most 16382 bytes of STREAM payload in one record, after accounting for the 2-byte record length field. 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 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. The record-less approach that we are discussing here requires trial or incremental frame decoding, which is a departure from QUIC version 1, and provides a weaker mechanism for aligning STREAM frame boundaries with TLS record boundaries. As you have previously noted, that approach works when the sender emits just one STREAM frame and nothing else. All that said, I think part of the difficulty here is that we do not have a concrete counter-proposal to QMux records. I initially assumed that you were advocating a design that (1) prohibits the use of STREAM frames omitting the length field, and (2) does not impose a size cap on STREAM frames. That design has the downside of requiring every stack to implement incremental processing of streams, but by doing so it naturally prevents unnecessary buffering without relying on sender behavior. In your previous reply, however, you argued that there could be a record-less design in which STREAM frame boundaries and TLS record boundaries can align. My stated pushback is specifically against this variant, that such a property could be met only by specifying an upper limit on the STREAM frame size including the frame header, and that it would still be worse compared to the record-based approach, as stated above. I would appreciate it if you could clarify the exact design that you envision. That would make it easier to compare that design against the record-based approach. So how would the two designs be different regarding the TLS layer? > -- Kazuho Oku
