new draft: RELIABLE_RESET_STREAM

[Marten Seemann <[e-mail]>]

In RFC 9000 we defined a RESET_STREAM frame. When a stream is reset, the
receiver may deliver the reset error to the application immediately. On the
sender side, lost STREAM frames won't be retransmitted.
When building applications on top of QUIC, it is a common pattern to send
some kind of identifier (an ID or a string, for example) first, to allow
the application to route the stream to a subpart of that application. For
example, WebTransport sends the Session ID of the WebTransport Session.
Outside of the IETF, I've used something similar for layering various
applications on top of QUIC.

When a stream is reset, the receiver might end up unable to associate the
stream with the respective subpart of the application. This is problematic,
since

   1. depending on the application protocol, a reset of a stream might
   carry application-layer semantics, and
   2. the RESET_STREAM only closes one side of the stream, and it might
   depend on the (sub-) application how the other direction of the stream is
   handled

This problem is not unique to WebTransport, but occurs for every
application using some kind of stream identifier. It might make sense to
design a solution at the QUIC layer.

I've just submitted a draft that aims to solve this problem:
https://datatracker.ietf.org/doc/draft-seemann-quic-reliable-stream-reset/
It defines a RELIABLE_RESET_STREAM frame, which is essentially
a RESET_STREAM frame with one additional field, the Reliable Size. The
sender of the RELIALBE_RESET_STREAM frame commits to (re-)transmitting
stream data up to the Reliable Size reliably, and the receiver delivers
data up to that offset to the application before surfacing the reset error.
In WebTransport, you'd set the Reliable Size such that it covers everything
up the Session ID, thereby making sure that any stream can always be routed
to its WebTransport session.

Obviously, there are use cases for this draft beyond the reliable
transmission of just a stream identifier. One could imagine an application
protocol that would benefit from being able to have the first part of an
actual application-layer message being delivered reliably. I'm happy about
enabling those use cases, but I've avoided making this draft more
complicated than necessary by accommodating the more general cases.