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. 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.)
