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

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Apr 2017 15:07:54 -0700

MikeBishop commented on this pull request.

> @@ -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 think you're right -- the point of DISINTEREST is that sender's data channel remains open, so it can communicate any reasons it might have there.

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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Apr 2017 15:16:45 -0700

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

It kind of _is_ squishy, at least in my mind.  DISINTEREST is a courtesy notification that your data is being ignored, so you might as well stop sending it.  Converting that to a MUST is to put more semantics on it than I had intended.  Notably, this is also hard behavior to verify in a peer -- you'd have to look for STREAM frames in a later packet than the ACK of the DISINTEREST, I suppose.

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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Apr 2017 15:18:25 -0700

@MikeBishop pushed 2 commits.

5088ec5  Merge remote-tracking branch 'origin/master' into request_rst
df92cb1  Martin's less-MUSTy feedback on DISINTEREST

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Apr 2017 23:03:23 -0700

martinthomson approved this pull request.

I think that the semantics we want here are "DISCARD", not "DISINTEREST".

FWIW, I also think that the semantics for RST_STREAM are "CANCEL" rather than "RESET".  "RESET" implies TCP RST semantics, which aren't appropriate for QUIC. I'd like to get away from our TCP legacy where possible.

+|                        Stream ID (32)                         |
+The fields are:
+
+* Error code: A 32-bit error code which indicates why the data is being
+  discarded.

This field is shown in the figure.

> @@ -2526,6 +2571,9 @@ QUIC_CLOSED_CRITICAL_STREAM (0x80000007):
 QUIC_MISSING_PAYLOAD (0x80000030):
 : The packet contained no payload.
 
+QUIC_RECEIVED_RST (0x80000035):
+: Terminating stream because peer sent a RST_STREAM or DISINTEREST.

Having just gone over the error codes, I think that NO_ERROR is perfectly appropriate for this.  You have removed the existing one-way semantic from RST_STREAM+NO_ERROR and put that in a new frame, but the idea remains that there are cases for RST_STREAM where the stream just isn't wanted any more.  NO_ERROR fits perfectly to my mind.

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 24 Apr 2017 10:21:31 -0700

I would probably call that a "CANCEL," but I agree we can merge them if NO_ERROR's special-case semantics are gone.

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 24 Apr 2017 10:23:27 -0700

I'm curious....  Data in flight becomes ignorable, won't be retransmitted, and the stream is abruptly closed.  That actually *does* sound quite a bit like TCP RST to me.  While I'm not particularly wedded to either term, perhaps you should clarify what you see as the salient differences, so we can call them out in the spec?

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Apr 2017 15:41:37 -0700

martinthomson commented on this pull request.

"CANCEL" in h2 means "I didn't do anything with this stream", which mightbe nice to keep.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Apr 2017 15:54:55 -0700

Yes, RESET is still probably OK, the challenge here being how we manage the public reset (a connection-level abort) and a stream reset both having the same name.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Apr 2017 16:38:26 -0700

@janaiyengar had an idea that we at least wanted to float here.  In that design, DISINTEREST carries a maximum read offset.  That would be equivalent to RST_STREAM in the opposite direction.  It means that the sender would have no choice about whether to continue to send or not (in this design, DISINTEREST can be ignored).

The cost of saving a message is that you no longer have a single authoritative source for the end of stream offset.  The value in DISINTEREST would override the value in RST_STREAM (if both are sent in a race, DISINTEREST would always be less than or equal to the value in RST_STREAM, so it would win).  That means that in some cases the connection flow control window would have to go backwards.  Also, STREAM frames that arrive beyond the offset would have to be dropped (this would happen before any flow control policing, whereas today order of processing doesn't matter much).

On balance, I prefer the DISINTEREST design, but on complexity ground only.  I can't see why it wouldn't be equally valid.

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