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

[Roberto Peon <[e-mail]>]

Nit: messages almost always have a known length, while streams are a superset which may/may not have a known length, and address spaces are supersets of streams.

Yes, still sad we're not making address spaces work.

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: QUIC <[e-mail]> on behalf of Mike Bishop <[e-mail]>
Sent: Wednesday, March 20, 2024 3:55:45 PM
To: Matt Joras <[e-mail]>; Marten Seemann <[e-mail]>
Cc: QUIC WG <[e-mail]>; WebTransport <[e-mail]>
Subject: RE: Head-of-Line-Blocking of WebTransport Flow Control Messages

I agree with Matt. Unidirectional streams are messages, simply without the MTU length restriction. The feature Marten’s draft defines which isn’t present is the application’s ability to cancel/modify the message in case retransmission is needed. 
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd

I agree with Matt. Unidirectional streams are messages, simply without the MTU length restriction. The feature Marten’s draft defines which isn’t present is the application’s ability to cancel/modify the message in case retransmission is needed. A similar effect can be achieved on unidirectional streams by canceling the old stream and sending a new one when a new instance is ready to be sent.



If WebTrans chooses to register a Single Capsule stream type in HTTP/3, they can do that either now or as an extension. (In either case, they would still need to define an internal framing layer to tie the stream/MESSAGE to the WebTransport session, similar to H3 Datagrams.)



From: QUIC <[e-mail]> On Behalf Of Matt Joras
Sent: Sunday, March 17, 2024 12:30 PM
To: Marten Seemann <[e-mail]>
Cc: QUIC WG <[e-mail]>; WebTransport <[e-mail]>
Subject: Re: Head-of-Line-Blocking of WebTransport Flow Control Messages



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<https://www.rfc-editor.org/rfc/rfc9308.html#name-use-of-streams>



On Sun, Mar 17, 2024, 12:14 PM Marten Seemann <[e-mail]<mailto:[e-mail]>> wrote:

The current proposal (https://datatracker.ietf.org/doc/draft-thomson-webtrans-session-limit/<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<https://marten-seemann.github.io/draft-seemann-quic-reliable-message/draft-seemann-quic-reliable-message.html>