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 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).