Re: [quicwg/base-drafts] Independent states and DISINTEREST (#171)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

I'm making these comments on the assumption of choosing option 1.  There's a lot more to do if option 3 is chosen, particularly around the stream state machine.

> @@ -1599,6 +1601,32 @@ Final offset:
   data written on this stream by the RST_STREAM sender.
 
 
+
+
+## DISINTEREST Frame {#frame-disinterest}
+
+An endpoint may use a DISINTEREST frame (type=0x08) to communicate that incoming
+data is being discarded on receipt at application request.  This signals a peer
+to abruptly terminate transmission on a stream.  The frame is as follows:
+
+~~~
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        Error Code (32)                        |

I don't think that we need an error code here.  If we do, and there are semantics attached to that code, then that's an argument to move this to the application protocol, where the semantics can gain context.

> @@ -2018,7 +2047,26 @@ implementations SHOULD treat the receipt of a frame that is not expressly
 permitted in the description of a state as a connection error
 ({{error-handling}}). Frames of unknown types are ignored.
 
-(TODO: QUIC_STREAM_NO_ERROR is a special case.  Write it up.)
+
+## Solicited State Transitions
+
+If an endpoint is no longer interested in the data being received, it MAY send a
+DISINTEREST frame on a stream in the "open" or "half-closed (local)" state to
+request closure of the stream in the opposite direction.  This typically
+indicates that the receiving application is no longer reading from the stream
+and all future data will be discarded upon receipt.

... "However, it doesn't imply a guarantee that the receiver will discard data, the sender still needs to either reset the stream or complete its transmission of data."

> +If an endpoint is no longer interested in the data being received, it MAY send a
+DISINTEREST frame on a stream in the "open" or "half-closed (local)" state to
+request closure of the stream in the opposite direction.  This typically
+indicates that the receiving application is no longer reading from the stream
+and all future data will be discarded upon receipt.
+
+STREAM frames received after sending DISINTEREST are still counted toward the
+connection and stream flow-control windows.  Even though these frames will be
+discarded, because they are sent before their sender receives the DISINTEREST,
+the sender will consider the frames to count against its flow-control windows.
+
+Upon receipt of a DISINTEREST frame, an endpoint SHOULD send a RST_STREAM with
+an error code of QUIC_RECEIVED_RST.  If the DISINTEREST frame is received on a
+stream that is already in the "half-closed (local)" or "closed" states, a
+RST_STREAM frame SHOULD still be sent and retransmission of previously-sent
+STREAM frames SHOULD be cancelled.

We gots to get us some MUST here.  This isn't squishy.  The only real exemption to needing a RST_STREAM here is if the stream is long done.  If the sender is still (re)transmitting anything, then it needs to either finish that or move over to (re)transmitting a RST_STREAM.  Otherwise we have a wrinkle on the state machine and I don't want that, even if it could save a RST_STREAM.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/171#pullrequestreview-25960065