Re: QMux outcomes from IETF 125

[Christian Huitema <[e-mail]>]

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