Re: Reliable Stream Resets: Requesting a Reset at a Specific Offset

[Mathis Engelbart <[e-mail]>]

We also discussed this at the AVTCORE interim meeting in September. In 
RTP over QUIC, receivers may want to use STOP_SENDING to signal that a 
media frame will arrive too late and will be dropped. RTP over QUIC also 
uses length fields to signal the length of the next RTP packet, so a 
receiver could use an ENOUGH frame to indicate where it wants to stop 
reading. However, the receiver can only signal that it wants to finish 
reading an earlier frame but will drop the later one. I don't think that 
will happen very often because I don't see many reasons to keep reading 
older frames if a newer one is already deemed too late. It may be useful 
if the earlier frame is a dependency of even later frames, but those 
will likely also depend on the dropped frame. Thus, I don't expect it to 
be used much in RTP over QUIC.

On 10/10/23 07:37, Marten Seemann wrote:
> The Reliable Reset draft introduces a CLOSE_STREAM frame that allows 
> resetting a stream at a specific offset, thereby guaranteeing the 
> reliable delivery of stream data up that offset.
> 
> At IETF 117, there was some discussion (mainly in AVT) about whether 
> there should be a method for an endpoint to abort reading at a specific 
> offset. This would allow an endpoint to communicate that it's only 
> interested in the first N bytes of the stream, and that it will discard 
> all bytes beyond N. This could be done by introducing a STOP_SENDING 
> frame that carries an extra field to carry the value N.
> 
> This might be useful if the stream is used to send a sequence of 
> (TLV-encoded) media frames, and the receiver knows the size of the frame 
> before actually receiving the entirety of it, or in cases where the 
> receiver possesses out-of-band knowledge about the frame size.
> 
> I created a PR to make this proposal more specific: 
> https://github.com/quicwg/reliable-stream-reset/pull/26 
> <https://github.com/quicwg/reliable-stream-reset/pull/26>. This PR is 
> based on Martin Thomson's ENOUGH draft 
> (https://datatracker.ietf.org/doc/draft-thomson-quic-enough/ 
> <https://datatracker.ietf.org/doc/draft-thomson-quic-enough/>).
> 
> Is this mechanism actually useful enough to be included in the draft? 
> Implementing support for this frame seems quite easy, but it would be 
> helpful to learn more about use cases it enables first.