Hi Martin,
We discussed STOP_SENDING in RTP over QUIC during the AVTCORE session
this week. RTP over QUIC allows senders to send one or multiple media
frames on the same QUIC stream, but it would be nice if a receiver could
ask the sender to stop sending a media frame, e.g., because it is
arriving too late. But that doesn't work since the receiver can't know
if the sender intends to continue sending further media frames on the
same stream. The client doesn't want to cancel all the following frames,
just the current one. But if a sender receives STOP_SENDING, it doesn't
know which one is the current frame and from where to continue with a
new stream. ENOUGH could help with recovery by letting the sender know
where to reset the stream (using RESET_AT) and open new streams with new
media frames.
Best,
Mathis
On 3/31/23 17:17, Lucas Pardue wrote:
Hi Martin,
I was talking with Mathis after AVTCORE this week. They might actually
have a concrete use case for this, for RTP over QUIC.
Cheers
Lucas
On Fri, 31 Mar 2023, 17:00 Martin Thomson, <[email protected]
<mailto:[email protected]>> wrote:
Martin Duke asked if there was an analogue for STOP_SENDING to go
with Marten Seemann's proposal for "partial reset" or what I've
inferred we'll call RESET_AT or RESET_STREAM_AT.
Here:
https://datatracker.ietf.org/doc/html/draft-thomson-quic-enough
<https://datatracker.ietf.org/doc/html/draft-thomson-quic-enough>
This is not a very serious proposal, but it seems harmless enough.
