Speaking personally, I think this would be a confusing semantic to add to QUIC. RFC 9308[1] says of streams:
> Streams can provide message orientation and allow messages to be canceled. If one message is mapped to a single stream, resetting the stream to expire an unacknowledged message can be used to emulate partial reliability for that message. Indeed when discussing QUIC with application designers I often find myself explaining streams as arbitrarily lengthed messages that can even be made partially reliable. Introducing what is essentially a reliable datagram undermines the value proposition of streams over datagram-like abstractions, which I believe have less utility to applications in general. While this draft seems to be solving a real issue for WebTransport I would hope we could come up with a different solution that doesn't unintentionally reinforce the idea that QUIC streams are as semantically limited as stream sockets of yore. Best, Matt Joras [1] https://www.rfc-editor.org/rfc/rfc9308.html#name-use-of-streams On Sun, Mar 17, 2024, 12:14 PM Marten Seemann <[email protected]> wrote: > The current proposal ( > https://datatracker.ietf.org/doc/draft-thomson-webtrans-session-limit/) > for transmitting flow control messages serializes the capsules onto the > WebTransport control stream. Since the control stream is a QUIC stream, > this means that these messages suffer from HoL blocking in the case of > packet loss. > Depending on the usage pattern of the WebTransport application, this will > matter more or less. > > Here's an alternative way to solve this problem: By allowing WebTransport > to send the flow control messages / capsules directly on the QUIC > connection, these messages can be transmitted independently from each > other. This can be achieved by introducing a new QUIC frame: the MESSAGE > frame. MESSAGEs are kind of similar to DATAGRAM frames, with the important > distinction that MESSAGE frames are 1. delivered reliably to the > application, and 2. retransmitted / updated in case of packet loss. > > For more details, please refer to my (very early-stage) draft: > https://marten-seemann.github.io/draft-seemann-quic-reliable-message/draft-seemann-quic-reliable-message.html >
