Fix normative language about STOP_SENDING #96
Conversation
| @@ -490,17 +490,16 @@ RESET\_STREAM frame. | |||
| QUIC allows an application to abort reading the stream and specify an error code | |||
| {{Section 3.5 of !RFC9000}}. An RTP receiver can signal this to the RTP sender | |||
| by sending a QUIC STOP\_SENDING frame, which is exported to the RTP sender | |||
| through the ROQ API, as described in {{api-considerations}}. The RTP-sender | |||
| SHOULD not interpret the reception of STOP\_SENDING as an indication that the | |||
There was a problem hiding this comment.
I know this seems ridiculous, but "SHOULD" and "SHOULD NOT" are defined terms in BCP14, and "SHOULD not" is not. Although "SHOULD not" would be clear to many readers, it's not actual requirements language. 😇
There was a problem hiding this comment.
I think we don't need any requirements language here, do we?
| whole, but rather that a part of the media stream was not received timely. In | ||
| this case, the late data could also delay the following media frames due to | ||
| head-of-line blocking, which the sender can avoid by transmitting new media | ||
| frames on new QUIC streams. A sender that receives STOP\_SENDING MUST NOT |
There was a problem hiding this comment.
This might be clearer as two sentences:
"In
this case, the late data could also delay any following media frames due to
head-of-line blocking within a single QUIC stream. The RTP sender can avoid these delays by transmitting new media
frames on new QUIC streams."
I put what seemed like significant changes in bold, so you could spot them more easily. Please let me know if I misunderstand your intended meaning.
| head-of-line blocking, which the sender can avoid by transmitting new media | ||
| frames on new QUIC streams. A sender that receives STOP\_SENDING MUST NOT | ||
| retransmit any media frames already sent on the QUIC stream, on which it | ||
| received the STOP\_SENDING, on a new QUIC stream. An RTP sender MUST continue to |
There was a problem hiding this comment.
I made this more complicated than it needed to be. See if this is easier to understand.
"A QUIC sender that receives STOP_SENDING on a QUIC stream MUST NOT
retransmit any media frames already sent on that QUIC stream, on any QUIC stream."
| that received STOP\_SENDING. | ||
| through the ROQ API, as described in {{api-considerations}}. STOP\_SENDING is | ||
| not an indication that the RTP receiver lost interest in the media stream as a | ||
| whole, but rather that a part of the media stream was not received timely. In |
There was a problem hiding this comment.
OK, this is super awkward. I think we've gotten confused about the difference between what a QUIC receiver thinks it means when it sends "STOP_SENDING", and what an RTP receiver thinks it means.
From RFC 9000:
If the stream is in the "Recv" or "Size Known" state, the transport SHOULD signal this by sending a STOP_SENDING frame to prompt closure of the stream in the opposite direction. This typically indicates that the receiving application is no longer reading data it receives from the stream, but it is not a guarantee that incoming data will be ignored.
So, it looks like the application HAS lost interest - because the media frames are arriving late enough that they are not useful. The application is sending "STOP_SENDING" to trigger an automatic "RESET_STREAM".
What's confusing, is that the RTP receiver - the application - hasn't lost interest in the media - it's lost interest in getting outdated and unusable media frames. The RTP receiver wants the RTP sender to start over, with the most current media frames, on a stream that doesn't already hold additional outdated frames.
Does that make sense?
Assuming so, the text in this part of the document should reflect that distinction.
There was a problem hiding this comment.
Yes, that sounds correct.
| retransmit any media frames already sent on the QUIC stream, on which it | ||
| received the STOP\_SENDING, on a new QUIC stream. An RTP sender MUST continue to | ||
| send media frames on new QUIC streams starting with the first frame that was not | ||
| transmitted on the stream that received STOP\_SENDING. | ||
|
|
There was a problem hiding this comment.
Are we mandating that RTP senders open a new stream and continue sending?
If we are, and a RTP receiver really has stopped caring about this RTP stream, how does it "turn the RTP sender off"?
I think we're basically telling a RTP receiver that wants to "skip forward to usable media frames", to transmit a "STOP_SENDING" frame, triggering a "STREAM_RESET", and then to carry out another SDP exchange so the RTP sender knows that it should continue by sending the newest media frames on a new QUIC stream.
Do you see another way to ensure that the Right Thing happens?
Does that make sense?
There was a problem hiding this comment.
Are we mandating that RTP senders open a new stream and continue sending?
Yes, I think that is what we should do.
If we are, and a RTP receiver really has stopped caring about this RTP stream, how does it "turn the RTP sender off"?
I don't think using STOP_SENDING is the right tool for this. Instead, it would probably require some signaling.
I think we're basically telling a RTP receiver that wants to "skip forward to usable media frames", to transmit a "STOP_SENDING" frame, triggering a "STREAM_RESET", and then to carry out another SDP exchange so the RTP sender knows that it should continue by sending the newest media frames on a new QUIC stream.
Do you see another way to ensure that the Right Thing happens?
I don't understand why we would carry out another SDP exchange here. The sender should take STOP_SENDING as a signal that the receiver is still interested in the media stream in general, but wants to start over with new media frames on new QUIC streams.
|
@mengelbart is working on PR #98 which should replace this PR when it is merged. We're not working on this PR further, so please look at #98 instead. |
No description provided.