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

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.

This largely LGTM. A few minor comments, and I'm happy to approve once they are addressed.

> @@ -2527,6 +2549,32 @@ Reordering might cause frames to be received after closing, see
 {{state-hc-remote}}.
 
 
+## Solicited State Transitions
+
+If an endpoint is no longer interested in the data being received, it MAY send a
+STOP_SENDING frame on a stream in the "open" or "half-closed (local)" state to
+request closure of the stream in the opposite direction.  This typically

Editorial nit: does it make sense to say "request", since it's more of a "demand"? I can't come up with better wording, but maybe "require"? Up to you.

> @@ -275,11 +275,12 @@ fully closed.
 A server can send a complete response prior to the client sending an entire
 request if the response does not depend on any portion of the request that has
 not been sent and received. When this is true, a server MAY request that the
-client abort transmission of a request without error by sending a RST_STREAM
-with an error code of NO_ERROR after sending a complete response and closing its
-stream. Clients MUST NOT discard responses as a result of receiving such a
-RST_STREAM, though clients can always discard responses at their discretion for
-other reasons.
+client abort transmission of a request without error by triggering a QUIC
+STOP_SENDING with error code HTTP_EARLY_RESPONSE, sending a complete response,
+and cleanly closing its streams. Clients MUST NOT discard complete responses as
+a result of receiving a STOP_SENDING, though clients can always discard

HTTP clients won't receive a STOP_SENDING, since that's a QUIC frame (I realize that this was similar earlier with RST_STREAM)... perhaps something like "as a result of receiving a solicited stream reset"? I don't have better ideas.

> @@ -275,11 +275,12 @@ fully closed.
 A server can send a complete response prior to the client sending an entire
 request if the response does not depend on any portion of the request that has
 not been sent and received. When this is true, a server MAY request that the
-client abort transmission of a request without error by sending a RST_STREAM
-with an error code of NO_ERROR after sending a complete response and closing its
-stream. Clients MUST NOT discard responses as a result of receiving such a
-RST_STREAM, though clients can always discard responses at their discretion for
-other reasons.
+client abort transmission of a request without error by triggering a QUIC
+STOP_SENDING with error code HTTP_EARLY_RESPONSE, sending a complete response,
+and cleanly closing its streams. Clients MUST NOT discard complete responses as
+a result of receiving a STOP_SENDING, though clients can always discard
+responses at their discretion for other reasons.  Servers SHOULD NOT abort a

Why a MUST NOT above with clients and SHOULD NOT here with server behavior?

> + 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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        Stream ID (32)                         |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        Error Code (32)                        |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+
+The fields are:
+
+Stream ID:
+: The 32-bit Stream ID of the stream being ignored.
+
+Error Code:
+: The reason the sender is ignoring the stream, or QUIC_NO_ERROR if not due to
+  an error.

Isn't this always an application error code and never a QUIC one? If so, can we simply say this is for the application to specify and consume, as one of the app-specified error codes? I don't think you need a QUIC_NO_ERROR in this case.

>  the terminal STREAM frame that contains a FIN flag.
 
-A stream becomes "closed" when the endpoint sends and receives acknowledgment of
-a RST_STREAM frame.
+A stream also becomes "closed" when the endpoint sends a RST_STREAM frame.

This shouldn't have required an ack to be received in the first case. The stream state machine does not include retransmission logic -- that is considered to be a task for the reliabiity machinery "below".

> @@ -2527,6 +2546,26 @@ Reordering might cause frames to be received after closing, see
 {{state-hc-remote}}.
 
 
+## Solicited State Transitions
+
+If an endpoint is no longer interested in the data being received, it MAY send a
+STOP_SENDING 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,
+but is not a guarantee that incoming data will be ignored.
+
+STREAM frames received after sending STOP_SENDING are still counted toward the

This is a requirement now, right? I don't think we need to specify enforcement though... that seems like a bit of an overkill. Besides a sender of STOP_SENDING will have to make assumptions about how the peer's sending code is structured to make an assessment of when to consider the peer in error. For instance, the peer may have buffered data that gets drained after the received STOP_SENDING is acked... surely not a good way to write that code, but there's no reason to require this not happen.

-- 
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-53654548