Subject: [quicwg/base-drafts] STOP_SENDING in Ready state (#1797)

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Sep 2018 09:36:34 -0700

Section 7.15 of the current editor's draft states:
> Receiving a STOP_SENDING frame for a send stream that is “Ready” or non-existent MUST be treated as a connection error of type PROTOCOL_VIOLATION.

To put it another way, if an endpoint wants to abruptly discard a bidirectional stream that it has opened, it needs to either:
* wait for the peer to send a STREAM frame before sending STOP_SENDING
* bundle an empty STREAM frame (offset=0, len=0, FIN not set) when sending a STOP_SENDING frame

However, either of the two solution seems like an unnecessary complexity.

Can't we simply state that a STOP_SENDING frame implicitly creates a send stream before it is applied?

-- 
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/issues/1797

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Sep 2018 18:04:20 +0000 (UTC)

Seems reasonable.  Do you think that you could make a PR for this?  I assume that you want to limit this to bidirectional streams.  We don't want STOP_SENDING to be used as a means of using unidirectional streams.

-- 
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/issues/1797#issuecomment-424443788

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Sep 2018 11:09:51 -0700

Yes. This should be limited to bidirectional streams. I'll try to come up with a PR.

-- 
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/issues/1797#issuecomment-424445663

---

From: Mike Bishop <[email-masked]>
Date: Wed, 26 Sep 2018 16:48:07 -0700

This seems like an oversight, so I'm in favor of correcting in.  However, I'm not entirely convinced it's unreasonable to send STOP_SENDING preemptively for unidirectional streams either.

If you had advance knowledge of what was going to be on that stream (think HTTP/2-style PUSH_PROMISE), it might be reasonable to send STOP_SENDING for a stream that hasn't actually had data sent yet.  You can presume the data is in flight based on other application state, for example.

This might also be used to "claw back" unidirectional stream ID space -- you sent MAX_STREAM_ID=4X, then decide to shrink it by sending a STOP_SENDING on X-N streams, though that might not be a pattern we want to encourage.

-- 
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/issues/1797#issuecomment-424906757

---

From: Mike Bishop <[email-masked]>
Date: Wed, 26 Sep 2018 16:50:40 -0700

...thus a simpler fix might be to remove the prohibition, and simply clarify that the delayed allocation of Stream ID only applies to locally-initiated streams.

-- 
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/issues/1797#issuecomment-424907175

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 26 Sep 2018 17:38:10 -0700

@MikeBishop Clarification question: you seem to argue that it is not "unreasonable to send STOP_SENDING preemptively for unidirectional streams", and that we should "clarify that the delayed allocation of Stream ID only applies to locally-initiated streams".

However, my understanding is that if sending STOP_SENDING for unidirectional streams can only be done for remotely-initiated streams, by endpoints that have prior knowledge of what the stream ID of those streams would be.

So to me it seems that we can only have either one of the properties; i.e. either allow sending STOP_SENDING preemptively, or disallow delayed allocation of stream IDs.

Regarding the general idea of having a prior knowledge of what the stream IDs will be used for, I am not sure if we want to allow (or encourage) that type of design. IIUC we discussed that and the conclusion was to introduce the "type" octet for the unidirectional streams in the HTTP binding. I prefer sticking to the decision we made.

-- 
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/issues/1797#issuecomment-424916478

---

From: MikkelFJ <[email-masked]>
Date: Thu, 27 Sep 2018 06:27:29 +0000 (UTC)

We cannot have allow stream state modifying messages from peer on streams that have not yet been opened by the initiator, or which have been closed or forgotten. The exception is that if a higher stream is opened than a previously openened, the prevoiusly unopened stream is implicitly opened.

If STOP_SENDING could happen on a future stream and it could happen on much higher valued streams and this cannot be managed other than by ignoring or producing an error - where an error is the better option.

If STOP_SENDING is intended for an implicitly opened stream, there shouldn't be any problems, so if this "based on prior knowledge" is the fact that a higher stream was opened, then I guess it is fine.

-- 
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/issues/1797#issuecomment-424973577

---

From: MikkelFJ <[email-masked]>
Date: Wed, 26 Sep 2018 23:34:18 -0700

After some more though - if STOP_SENDING is allowed on any stream that has not been closed and which is within a previously transmitted MAX_STREAM_ID value, I guess it could reasonably work, but you risk our of order conflicts on 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/issues/1797#issuecomment-424974870

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Sep 2018 18:01:24 +0000 (UTC)

Closed #1797 via #1802.

-- 
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/issues/1797#event-1871762170