Hiya, Responding with no hats
On Thu, Mar 26, 2026, at 07:46, Kazuho Oku wrote: > > > 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? I tend to agree, based on the discussion, that the current state feels amongst the worst options. If we cannot find a consensus at the moment, in order to make progress in other areas, one possible path is for a 01 draft to punt on the matter by temporarily prohibiting frames without a length field and dropping the max_frame_size TP. That simplifies the protocol and implementations a bit. Cheers Lucas
