And I'll note that an optimized decoder can incrementally process STREAM frames with or without the QMux record layer proposal. Nothing prevents a decoder from processing an incomplete QMux record and flushing partial STREAM frame data, pending the next TLS record with the rest of the QMux record.
But note that this optimization only applies when the encoder is unaware of TLS record boundaries. An optimized encoder should align QMux record/frame boundaries with TLS record boundaries, even though the draft doesn't mandate it. In my opinion, adding a QMux record layer is worth it. It wastes a byte *sometimes* but it makes decoding easier via an upfront length (similar to QUIC), instead of requiring a length within the last STREAM frame. On Thu, Mar 26, 2026 at 8:52 AM Christian Huitema <[email protected]> wrote: > On 3/26/2026 2:41 AM, Kazuho Oku wrote: > > ... > > > That brings me back to QMux records. > > > > QMux records do not prohibit receivers from processing a STREAM frame > > incrementally. Blocking is a non-concern for such receivers. At the > > same time, if a sender aligns TLS record boundaries and QMux record > > boundaries — which I think there are good reasons to do [2] — then > > blocking due to partial delivery is also avoided for any type of > > receiver, including ones that block for a complete QMux record. > > > > Moreover, the defaults are specified such that these boundaries are > > likely to align naturally. > > > > Therefore, the problematic case is narrowed to one in which a sender > > chooses not to preserve that alignment, while a receiver also waits > > for a complete STREAM frame before making progress. > > > > Given that QMux is itself a fallback from QUIC, and considering that > > there are so many ways for implementations to hurt performance, I am > > not sure how much change to QUIC v1 we should force on every stack to > > avoid this bad outcome, when the problematic case seems like a corner > > case. > > > Let me second that. This discussion shows a tension between "QMUX is a > fallback when UDP is not available" and "QMUX is designed for maximum > performance, relieving the limitations imposed by UDP encapsulation". > > The arguments for unlimited stream frame size are based on performance. > The arguments for having a record layer are based on ease of > implementation, which fits well with the "fallback" design. > > I wonder how many QUIC implementations do the "incremental stream frame > processing" that Martin describes. They process UDP datagrams, which are > received maybe 1500 bytes at a time, and contain a set of whole frames. > Incremental processing would be quite a change. > > I am also very worried about the idea of not negotiating the maximum > size of either records of frames. That may be good for batch > performance, but it is dubious for real time application that have to > constantly evaluate the relative priority of streams. And it is really > not natural for small devices. > > My first priority is to have that negotiation. Implementations that > focus on performance may want to negotiate a very large record or frame > limit, up to 2^62 - 1 if they care, but I need to be able to negotiate a > smaller limit than that. > > Because my focus is to have "a robust way to cross UDP blocking > firewalls", and also to have as much commonality between QUIC and QMUX > as possible. > > -- Christian Huitema > > >
