Code change:
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> <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.

Related discussion:
text: 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.