Original text:
3.3. <del> A QUIC stream MAY be canceled at any point with an error code.  The producer does this via a "RESET_STREAM" frame while the consumer requests cancellation with a "STOP_SENDING" frame. When using "order", lower priority streams will be starved during congestion, perhaps indefinitely.  These streams will consume resources and flow control until they are canceled.  When nearing resource limits, an endpoint SHOULD cancel the lowest priority stream with error code 0. The sender MAY cancel streams in response to congestion.  This can be useful when the sender does not support stream prioritization. TODO: this section actually describes stream cancellation, not session cancellation.  Is this section required, or can it be deleted, or added to a new "workflow" section. </del>  3.4.

Reviewer comments:
Section 3.3 currently says: "3.3. Cancellation A QUIC stream MAY be canceled at any point with an error code. The producer does this via a RESETSTREAM frame while the consumer requests cancellation with a STOPSENDING frame. When using order, lower priority streams will be starved during congestion, perhaps indefinitely. These streams will consume resources and flow control until they are canceled. When nearing resource limits, an endpoint SHOULD cancel the lowest priority stream with error code 0. The sender MAY cancel streams in response to congestion. This can be useful when the sender does not support stream prioritization. TODO: this section actually describes stream cancellation, not session cancellation. Is this section required, or can it be deleted, or added to a new "workflow" section." [BA] While the meaning of STOPSENDING is clear for frame/stream transport (e.g. stop sending the frame whose transmission is currently in progress), it is less clear when multiple frames are transported on the same QUIC stream. In the case where multiple frames are being transmitted on a stream, the problem is that STOPSENDING does not indicate which frame the receiver has given up on. So how is the sender to interpret it? For example, after resetting the stream, does the sender open a new stream? If so, what frame(s) are to be transmitted on that new stream? To address this ambiguity, an application-layer message(s) could be defined, indicating exactly what the receiver wants the sender to do: Stop (re-)transmission of a particular (named) frame. The existing stream is reset and a new stream is opened for transmission of subsequent frames. Stop transmission of layer(s). The receiver wishes to the sender to adjust the operating point, by stopping the transmission of one or more temporal or spatial layers. Only the layers that remain will be transmitted on new stream(s). Mailing list thread: URL
I think subscribe hints solves the problem of what to start on by saying which object to start the new subscription on. It seems like the solutions to layers would be to put different layers on differenent streams. I would expect different layers to have different priorities which will then mean different streams.
Attendees think there may be valid use cases of STOPSENDING and RESET and it should not be disallowed. But typically UNSUBSCRIBE could be used to accomplish the desired behavior. STOPSENDING and RESET do not change the state of subscriptions.
Yeah the problem is when there's significant congestion, a player can fall behind on the active subscription. It needs a way of indicating that it is not waiting for group X any longer so the server should not send it, otherwise it's just a waste of bandwidth. My proposal is to use STOPSENDING to indicate you don't want something. This does mean that you can't put unrelated objects on the same stream, otherwise you might accidentally reset the wrong objects. ex. If I no longer want to receive group X, I STOPSENDING any QUIC streams containing group X. But that does prohibit sending group Y on the same QUIC stream, so it would prohibit sending the entire track on a single stream. But like you forfeited the ability to skip any content if you decided to do that. Alternatively, we could add a STOPGROUP message or UNSUBSCRIBERANGE. Possibly we could RESUBSCRIBE with a new start group.
Resubscription works fine here. Since a new subscription is supposed to override an existing subscription from the client, Relay can start sending from the new group. Also I don't think we need to forfeit track per stream use-case. If someone is using track per stream, they exactly know what properties they are signing up for. My proposal would be to Subscribe with new start_point
Resubscribe only works if the content we don't want is at the head/tail, unless SUBSCRIBE supports ranges instead of a single start/end. We don't need to forfeit the use-case; the receiver would have to know that it can't cancel streams in this mode. Franky the application has already made a huge mistake if you're encountering congestion while sending all groups over the same stream. A UNSUBSCRIBE/SUBSCRIBE message doesn't work because it will cause redelivery of any duplicates. We would have to add RESUBSCRIBE or allow augmenting an existing SUBSCRIBE.
NAME Agree that STOPSENDING and RESETSTREAM do not change the state of subscriptions. I'd say the same for CLOSE_STREAM (see: URL).
Not with Subscription hints though
Yes , its application decision to prefer such a mode. Yes in such cases cancel will cancel the entire stream. But resubscription with a new start_point will help alleviate some.
The group spent time discussing ideas around RESUBSCRIBE/SUBSCRIBE_UPDATE and multiple subscriptions. NAME brought up the fact that a relay may have to issue overlapping subscribes because it doesn't know whether a relative or absolute subscription is earlier. This needs a new issue for multiple subscriptions and updating subscriptions.
Like the change. Section 3.3 currently says: "3.3. Cancellation A QUIC stream MAY be canceled at any point with an error code. The producer does this via a RESETSTREAM frame while the consumer requests cancellation with a STOPSENDING frame. When using order, lower priority streams will be starved during congestion, perhaps indefinitely. These streams will consume resources and flow control until they are canceled. When nearing resource limits, an endpoint SHOULD cancel the lowest priority stream with error code 0. The sender MAY cancel streams in response to congestion. This can be useful when the sender does not support stream prioritization. TODO: this section actually describes stream cancellation, not session cancellation. Is this section required, or can it be deleted, or added to a new "workflow" section." [BA] While the meaning of STOPSENDING is clear for frame/stream transport (e.g. stop sending the frame whose transmission is currently in progress), it is less clear when multiple frames are transported on the same QUIC stream. In the case where multiple frames are being transmitted on a stream, the problem is that STOPSENDING does not indicate which frame the receiver has given up on. So how is the sender to interpret it? For example, after resetting the stream, does the sender open a new stream? If so, what frame(s) are to be transmitted on that new stream? To address this ambiguity, an application-layer message(s) could be defined, indicating exactly what the receiver wants the sender to do: Stop (re-)transmission of a particular (named) frame. The existing stream is reset and a new stream is opened for transmission of subsequent frames. Stop transmission of layer(s). The receiver wishes to the sender to adjust the operating point, by stopping the transmission of one or more temporal or spatial layers. Only the layers that remain will be transmitted on new stream(s).

Revised text:
3.3.  <ins> QUIC streams aside from the control stream MAY be canceled due to congestion or other reasons by either the sender or receiver.  Early termination of a QUIC stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions. </ins> 3.4.