Re: Head-of-Line-Blocking of WebTransport Flow Control Messages

[Matt Joras <[e-mail]>]

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 <[e-mail]>
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
>