I also looked. Like Ian, there were a few issues that came out of the review I did.
The question of the two-layer framing is one that I've thought about. I've concluded that I strongly prefer the design where STREAM frames are always length-delimited. It's a miniscule amount more efficient. Either version includes a length, but the version with the length on one more STREAM frame will have a smaller value. And any time that there is no unterminated STREAM frame, the length is pure waste. It is true that the engineering cost of managing stream reads is significant. I can attest to that. Variable-length integers are pretty bad for this sort of processing, but many stacks already need the code for their HTTP/3 implementation, which has exactly this problem already. It would have been nice to put the code to handle undelivered-but-promised data in a single place, but that is only possible if you impose a performance penalty. A stack could use another framing layer to shield frame processing from having to block/pause when data is not yet available. But that leads to delays in processing. Any framing layer that bundles multiple frames would not be processed, even if the data for leading frames is present. That increases the costs of a reliable QMux implementation, which undercuts some of the promise that was made, but my view is that frame processing is such a small part of any implementation that it doesn't matter much. ~Martin On Sat, Mar 21, 2026, at 21:25, Ian Swett wrote: > Thanks for the progress and I apologize for missing the session. I > tried to provide helpful reviews where possible. > > The two-layer encoding Issue is the only one where I felt we were going > in the wrong direction, but I recognize I might not fully understand > the issues. > > Thanks, Ian > > On Fri, Mar 20, 2026 at 4:21 AM Lucas Pardue <[email protected]> wrote: >> __ >> Hi folks, >> >> At the 125 session, Kazuho presented several QMux open issues with >> associated PRs. This email serves to summarize the outcome of the discussion >> and confirm the feeling in the room on the list. >> >> Since there has seemed to be strong emerging consensus on GitHub and in the >> room, the authors would like to promptly follow up on the outcomes. If you >> disagree with them, please let that be known ASAP and before 2026-03-26, >> ideally on the issue or PR itself. >> >> As noted in the session, we'd like to schedule a virtual interim for QMux >> before IETF 126, targetting an EMEA friendly timeslot. Look out for a follow >> up email on that topic, in the meantime you can express your interest >> directly to the chairs. >> >> • Two-layer encoding >> • Issues: https://github.com/quicwg/qmux/issues/21 and >> https://github.com/quicwg/qmux/issues/24 >> • PR: https://github.com/quicwg/qmux/pull/26 >> • Outcome: merge the PR to close the issues >> • Deadlock and flow control >> • Issue: https://github.com/quicwg/qmux/issues/9 >> • PR: https://github.com/quicwg/qmux/pull/27 >> • Outcome: merge the PR to close the issue >> • TLS Profile - negotiating application protocol when using TLS >> • Issues: https://github.com/quicwg/qmux/issues/12 and >> https://github.com/quicwg/qmux/issues/25 >> • PR: https://github.com/quicwg/qmux/pull/33 >> • Outcome: merge the PR to close the issue >> • TLS Profile - QMux transport params (TPs) in TLS handshake >> • Issue: https://github.com/quicwg/qmux/issues/18 >> • PR: https://github.com/quicwg/qmux/pull/28 >> • Outcome: merge the PR and close the issue (the PR adds improved text >> but we will keep TPs in QMux frames >> • Implicit acks & ping >> • Issue: https://github.com/quicwg/qmux/issues/22 >> • PR: https://github.com/quicwg/qmux/pull/23 >> • Outcome: merge the PR to close the issue >> • Multipath TCP >> • Issue: https://github.com/quicwg/qmux/issues/5 >> • PR: https://github.com/quicwg/qmux/pull/29 >> • Outcome: do not merge the PR, close with no action >> Cheers, >> Lucas & Matt >> QUIC WG Chairs
