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.
