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

From: Mike Bishop <[email-masked]>
Date: Wed, 07 Jun 2017 07:30:59 -0700

@MikeBishop pushed 2 commits.

5740393  Martin's feedback
299e72d  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/3ac855012455203562ddbcbfa5b51a78dc05de8e..299e72d53afeb03d34d4b29e7ce1f79f1a6067de

---

From: Christian Huitema <[email-masked]>
Date: Wed, 28 Jun 2017 08:21:19 -0700

huitema requested changes on this pull request.

The DISINTEREST frame type should be listed in the # Frames and Frame Types {#frames} section of the transport specification. This is missing from the PR.

I would suggest adding an error code. This can be quite useful for debugging. 

I would like to see it just parallel the RST STREAM frame, i.e. with an indication of how much data the receiver wanted to get. But I can also see that not having a parameter makes the spec simpler, and that having the parameter can open to all kinds of funky attacks.

> +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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        Stream ID (32)                         |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+
+The fields are:
+
+* Stream ID: The 32-bit Stream ID of the stream being ignored.
+

I think it would be simpler to have exactly the same setup as RST: Error code, stream ID, and amount consumed. At least the error code, with the reason for sending the DISINTEREST. 

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 28 Jun 2017 08:29:20 -0700

The transport semantic discussion is a hard one. Suppose an API from the App to the Transport stating that "I am not interested in that stream". The transport can act locally, without telling anything to the peer: just drop all incoming STREAM frames for that stream. The peer will have no way to tell whether the frames were consumed or dropped. I do think that it would be better to send a DISINTEREST (or DISCARD) stream to tell the peer about that. I would add an error code in the frame, because diagnostic. 

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 28 Jun 2017 10:33:35 -0700

MikeBishop commented on this pull request.

There originally was, and @martinthomson suggested removing it (see his review in April).  The point of this frame is that the sender's side isn't inherently closed, so any reasons can still be communicated at the application layer.  That's certainly the case with HTTP, where the most common reason is that the server has already generated a response.  I have a mild preference for leaving it out, since this isn't targeted at error cases, but I'm largely ambivalent.  I'd suggest taking that design discussion to the issue or list.

Including the offset doesn't really matter -- the sender of DISINTEREST has received all the data they needed, which implies the receiver has already successfully sent at least that much.  Why do they care what the offset of not-caring was?  RST_STREAM includes the offset because that's necessary to synchronize flow control.  Not so here.

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 28 Jun 2017 10:34:54 -0700

Bah, you're right -- we lost the frame type field entry when I merged the changes with the updated flow control frames, I think.  Let me put that back....

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 28 Jun 2017 10:56:24 -0700

1536501  Merge remote-tracking branch 'origin/master' into request_rst
52f99c7  Update frame type value and table

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