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

From: Mike Bishop <[email-masked]>
Date: Mon, 24 Jul 2017 19:21:11 +0000 (UTC)

@MikeBishop pushed 1 commit.

15da4ce  Merge remote-tracking branch 'origin/master' into request_rst

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/171/files/52f99c7cf83c4d87c8f2ef41450a8a0343619af3..15da4ced14ace1ce9d2859c8fe357377b754970b

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Jul 2017 23:46:35 -0700

martinthomson approved this pull request.

So I don't think that we need an error code here, but I don't care if we do have one.  It creates some interesting error reporting dynamics, but that's manageable.

As for the name, can we go with STOP_SENDING or REQUEST_RST?  DISINTEREST is a little oblique.

> @@ -272,11 +272,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
+DISINTEREST with error code HTTP_EARLY_RESPONSE, sending a complete response,

We need to reconcile this error code business, otherwise, I think we're good to go.  (And I would like to resolve this soon.)

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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 27 Jul 2017 18:04:17 +0000 (UTC)

@MikeBishop pushed 2 commits.

35dfd02  Bring back the error code
e0be281  REQUEST_RST -> DISINTEREST -> STOP_SENDING

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/171/files/15da4ced14ace1ce9d2859c8fe357377b754970b..e0be281ea21903edc16675f958a1e33b170b8000

---

From: Mike Bishop <[email-masked]>
Date: Thu, 27 Jul 2017 18:03:59 +0000 (UTC)

I thought you were the one who originally proposed the name DISINTEREST?  But sure -- STOP_SENDING is probably clearest.

-- 
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#issuecomment-318440411

---

From: ianswett <[email-masked]>
Date: Thu, 27 Jul 2017 11:16:07 -0700

ianswett commented on this pull request.

Thanks for changing the name, I like this PR a lot better now.

> @@ -275,11 +275,12 @@ fully closed.
+and cleanly closing its streams. Clients MUST NOT discard complete responses as
+a result of receiving a DISINTEREST, though clients can always discard responses

You're still using DISINTEREST here and a few more spots.

> @@ -2696,11 +2741,12 @@ controller.
 
 ### Response to a RST_STREAM
 
-Since streams are bidirectional, a sender of a RST_STREAM needs to know how many
-bytes the peer has sent on the stream.  If an endpoint receives a RST_STREAM
-frame and has sent neither a FIN nor a RST_STREAM, it MUST send a RST_STREAM in
-response, bearing the offset of the last byte sent on this stream as the final
-offset.
+RST_STREAM terminates a stream abruptly.  Whether any action or response can or

This wording is a bit confusing now.  I think this should be "RST_STREAM closes the sender's direction of a stream abruptly." or something similar.  Also, this isn't just a new frame being added, this is essentially saying only the sender can close the send side of a 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-52738876

---

From: ianswett <[email-masked]>
Date: Thu, 27 Jul 2017 18:21:03 +0000 (UTC)

In regards to the error code, I'm happy to land this without one and then figure out how to use it later if that moves things along.

-- 
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#issuecomment-318445102

---

From: Mike Bishop <[email-masked]>
Date: Thu, 27 Jul 2017 18:59:27 +0000 (UTC)

MikeBishop commented on this pull request.

 

Yeah, I think I had done a better job of that, but then this section got bitrotten due to a rewrite on the main branch.  I went back through and tried to restore that again.

-- 
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#discussion_r129930122

---

From: Mike Bishop <[email-masked]>
Date: Thu, 27 Jul 2017 18:59:38 +0000 (UTC)

e91b428  DISINTEREST->STOP_SENDING in HTTP doc
1213176  Clarifying stream state

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/171/files/e0be281ea21903edc16675f958a1e33b170b8000..121317646f7ac70cf9ab58f88d91bcde7967af0d

---

From: ianswett <[email-masked]>
Date: Thu, 27 Jul 2017 20:26:06 +0000 (UTC)

ianswett approved this pull request.

One nit, but looks good.  Can you retitle the PR to Independent states and STOP_SENDING?

> @@ -2536,11 +2531,10 @@ mentions a stream ID.  In this state, the endpoint MUST observe advertised
 stream and connection data limits (see {{flow-control}}).
 
 A stream transitions from this state to "closed" by completing transmission of
-all data.  This includes sending all data carried in STREAM frames up including
-the terminal STREAM frame that contains a FIN flag.
+all data.  This includes sending all data carried in STREAM frames up to and

nit: I would just remove "up" and say "This includes sending all data carried in STREAM frames including the terminal STREAM frame that contains a FIN flag."

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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 27 Jul 2017 13:49:52 -0700

23c7dd2  delete 'up to and'

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/171/files/121317646f7ac70cf9ab58f88d91bcde7967af0d..23c7dd2953dabff330c1ed391f3f4b2c193d4cf1

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Jul 2017 01:03:45 +0000 (UTC)

🚢 🎉 

-- 
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#issuecomment-318527821

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 31 Jul 2017 16:04:28 +0000 (UTC)

siyengar commented on this pull request.

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

wouldn't we still have to wait for the ACK and retransmit the RST if not, why does this change?

> +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
+connection and stream flow-control windows.  Even though these frames will be
+discarded, because they are sent before their sender receives the STOP_SENDING,
+the sender will consider the frames to count against its flow-control windows.
+
+Upon receipt of a STOP_SENDING frame on a stream in the "open" state, an
+endpoint SHOULD send a RST_STREAM with an error code of QUIC_RECEIVED_RST.  If
+the STOP_SENDING frame is received on a stream that is already in the
+"half-closed (local)" or "closed" states, a RST_STREAM frame MAY still be sent
+in order to cancel retransmission of previously-sent STREAM frames.

This wording seems a bit strange to me. Why does sending a RST_STREAM frame cancel retransmission of STREAM frames, isn't canceling retransmission a decision made by the sender locally?

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

a sender of STOP WAITING can technically detect that a sender sent data after it got the stop waiting, should it error the connection in that case?

I might have missed a MUST behavior associated with STOP_WAITING. Is it still a recommendation and not a required behavior?

> @@ -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
+connection and stream flow-control windows.  Even though these frames will be
+discarded, because they are sent before their sender receives the STOP_SENDING,
+the sender will consider the frames to count against its flow-control windows.
+
+Upon receipt of a STOP_SENDING frame on a stream in the "open" state, an

is there a reason this requirement is only in open state and not in half-closed remote as well? 

This whole paragraph seems strangely worded, it just basically says, "Hey you can send a RST stream in response to a STOP_WAITING" any time. Does it add a lot of value to make QUIC_RECEIVED_RST a special case?

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 31 Jul 2017 17:51:50 +0000 (UTC)

Hm, that's probably a change that came after my PR forked and I lost in the merge.  But I thought the transition to "closed" on the sender was immediate on sending the frame? I'll have to look at history and see if I can find when that changed.

 {{state-hc-remote}}.

Recommendation.  STOP_SENDING is advisory that your data is being discarded and is pointless, but doesn't force a transition.  (The SHOULD is at the paragraph where your next comment was located.)

 {{state-hc-remote}}.

Good point on hc-remote -- I'll update that.  The point of the paragraph is that if you're currently transmitting data, you SHOULD cut it off.  If you're done transmitting data, but you might still have retransmissions going, you MAY reset the stream or just finish your retransmissions as normal, whichever is easier.

The QUIC_RECEIVED_RST error code is there to make it easier to distinguish RST-because-error from RST-because-you-said-to.

Kind of.  The spec says that a stream isn't closed until you've successfully delivered all STREAM frames up through the FIN flag; that means you have to keep retransmitting until everything gets through to close a stream that way.  However, if the recipient is actually ignoring your data anyway, it's not clear how tightly they'll hold you to that.

For state machine consistency, if you're not retransmitting data, you're supposed to (reliably) send a RST_STREAM to indicate that.

-- 
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#discussion_r130411452

---

From: Mike Bishop <[email-masked]>
Date: Mon, 31 Jul 2017 10:59:33 -0700

Looks like this text came in as part of #459, but it's inconsistent with the text in "open" which says that RST_STREAM causes transitions immediately on send, which I thought is what we'd agreed.  I'm going to leave it for now until @martinthomson can weigh in.

-- 
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#discussion_r130415895

---

From: Mike Bishop <[email-masked]>
Date: Mon, 31 Jul 2017 18:01:32 +0000 (UTC)

7a46965  STOP_SENDING in half-closed remote

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/171/files/23c7dd2953dabff330c1ed391f3f4b2c193d4cf1..7a46965980fead43cb964f27e5183e8014c941b5

---

From: Mike Bishop <[email-masked]>
Date: Mon, 31 Jul 2017 13:19:03 -0700

5699b82  Remove implied ordering of STOP_SENDING and STREAM frames

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/171/files/7a46965980fead43cb964f27e5183e8014c941b5..5699b82e4ce61cd90754038f0652568ecb625edb