2026年3月26日(木) 15:44 Martin Thomson <[email protected]>: > On Thu, Mar 26, 2026, at 16:26, Kazuho Oku wrote: > > Without a record layer, the equivalent constraint would be to say that > > the maximum size of a STREAM frame, including its frame header, is > > 16384 bytes. > > That seems like a reasonable implementation strategy. I wouldn't mandate > it in the protocol though. > > > That is what I am trying to point out. The record-based approach does > > not require changes to frame decoders, and it works regardless of the > > type and number of QUIC frames the sender chooses to send. > > Yes, the record layer makes it easier to implement. My point is that it > in doing so it encourages a poor implementation. > > > and provides a weaker mechanism for aligning STREAM frame boundaries > > with TLS record boundaries. > > I *think* that I understand your argument, but it wasn't obvious. Are you > saying that non-STREAM frames will be added to TLS records in ways that the > entity that generates STREAM frames might be unaware of, causing the STREAM > frame to overflow the TLS record? Can't you have a layer that tracks bytes > written so that it never lets a STREAM frame span a TLS record if you cared > about that? > > Of course, I don't think you should care about that. My view there is > that you can decode (and deliver!) the first half of a STREAM frame that is > split between TLS records. It requires incremental decoding of frames, but > I've been arguing that this is what you want anyway. > > > All that said, I think part of the difficulty here is that we do not > > have a concrete counter-proposal to QMux records. > > I thought that "don't change the draft" was the counter-proposal. That's > what I've been advocating for. (I apologize for maybe not being clear > about that.) >
Thanks, I think we are on the same page regarding how QMux records work, even though we might disagree on how effective they are in keeping frames and records aligned. However, I am uncertain if "don't change the draft" is the correct position to take if the concern is to encourage incremental decoding. 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. WDYT? -- Kazuho Oku
