2026年3月26日(木) 17:47 Martin Thomson <[email protected]>: > On Thu, Mar 26, 2026, at 18:46, Kazuho Oku wrote: > > As -00 stands today: > > * the payload of a STREAM frame MUST be no larger than 16,384 bytes, > > unless extended by transport parameter; > > * if the Length field of a STREAM frame is omitted, the frame extends > > to the maximum size. > > > > This feels to me like the worst of both worlds: > > 1. The maximum frame size is small enough that implementations might > > choose to wait for complete frames. > > 2. The design naturally leads to STREAM frames being split across > > multiple TLS records, because the maximum size of a STREAM frame > > including the frame header is slightly larger than what one TLS record > > can contain. This induces buffering in receivers waiting for complete > > frames. > > 3. It still requires receivers to modify their frame decoding strategy > > from QUIC v1 to handle partially received frames gracefully. > > > > Compared to such a design, QMux records seem better to me, because they > > fix (3) and mitigate (2). > > > > Instead, if *your* goal is to encourage incremental decoding, I think a > > design like H3 frames, with no limit on the maximum frame length, might > > be a better fit than -00. > > I'm not entirely sure what you are proposing there (frame length on every > frame, perhaps?) but I do agree that we get a bad outcome with the current > length limit on STREAM frames. >
I should have described this variant more clearly. Apologies. What I had in mind is: * require all STREAM frames to carry the Length field, * drop the max_frame_size transport parameter, so that STREAM frames can be arbitrarily large, and * keep the encoding of all other frame types identical to -00 (and therefore also to QUIC v1). I think this is exactly the possible interim solution that Lucas described in his other email [1]. That said, as you point out, there are good reasons not to send excessively large STREAM frames. Put differently, regardless of which design we choose, we end up relying on developers making sensible decisions. 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. [1] https://mailarchive.ietf.org/arch/msg/quic/inbs2ArfmPPCGkLWNbFOApA24eA/ [2] https://mailarchive.ietf.org/arch/msg/quic/_m_JvsbeEMPfT-V2LiCztavJodQ/ > It's worth remembering that limiting frame size does serve *a* purpose. > In HTTP/2, we limited stream frame size so that endpoints could react to > changes in their peer with less delay. > > That's still probably good advice here. If you need to send flow control > updates and you just committed to sending 100Mb of a STREAM frame, that's > not a great place to be. > > Of course, maybe we can start to trust implementers more and not force > them to use smaller frames. (Yes, I'm aware of the potential hypocrisy, > I'm shifting my mistrust a little, not all the way.) > -- Kazuho Oku
