Subject: [quicwg/base-drafts] STOP_SENDING on implicitly opened streams is error-prone (#2345)

From: Benjamin Saunders <[email-masked]>
Date: Thu, 17 Jan 2019 20:44:40 -0800

> A stream ID that is used out of order results in all streams of that type with lower-numbered stream IDs also being opened.

> Receiving a STOP_SENDING frame for a locally-initiated stream that is “Ready” or not yet created MUST be treated as a connection error of type STREAM_STATE_ERROR

Streams can easily become open while still in the `Ready` state on the sender if the sender does not necessarily transmit data on streams in exactly the order in which they are allocated. If the receiving application decides to abandon such a stream and sends STOP_SENDING, a connection error results.

If STOP_SENDING is additionally permitted for streams in the `Ready` state which have been implicitly opened by some higher-numbered stream of the same type entering any other state, then implicitly-opened streams can be safely discarded without waiting for a STREAM or RESET_STREAM frame which the application is no longer interested 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/issues/2345

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 17 Jan 2019 22:25:34 -0800

:+1:

> Streams can easily become open while still in the Ready state on the sender if the sender does not necessarily transmit data on streams in exactly the order in which they are allocated. If the receiving application decides to abandon such a stream and sends STOP_SENDING, a connection error results.

FWIW, this happens also when a packet carrying a STREAM frame with the smaller stream ID gets dropped.

-- 
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/2345#issuecomment-455440932

---

From: Benjamin Saunders <[email-masked]>
Date: Thu, 17 Jan 2019 22:28:41 -0800

> FWIW, this happens also when a packet carrying a STREAM frame with the smaller stream ID gets dropped.

Right, but in that case the sender's state is `Send` for the implicitly-opened stream, so a STOP_SENDING won't produce an error. The receiver of course has no way to distinguish those cases, and so currently cannot ever safely send STOP_SENDING on implicitly opened 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/2345#issuecomment-455441462

---

From: Marten Seemann <[email-masked]>
Date: Thu, 17 Jan 2019 23:07:45 -0800

I think the text should be
> Receiving a STOP_SENDING frame for a locally-initiated stream that is not yet created MUST be treated as a connection error of type STREAM_STATE_ERROR.

There's value in an endpoint being able to communicate that data from a stream won't be read, even if no data was ever sent on that stream before.

-- 
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/2345#issuecomment-455448227

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Jan 2019 09:01:26 -0800

Works for me.

-- 
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/2345#issuecomment-455616519

---

From: MikkelFJ <[email-masked]>
Date: Fri, 18 Jan 2019 22:08:42 -0800

Please review past discussions on this

#1050
#1797

-- 
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/2345#issuecomment-455753199

---

From: Benjamin Saunders <[email-masked]>
Date: Fri, 18 Jan 2019 22:54:36 -0800

I did review #1050 before opening this issue:
> Yes, we should prohibit the frame for streams that are not yet created.

It seems to me that the intention here was not to exclude implicitly opened streams, since by most reasonable interpretations they have indeed been created. Perhaps it was overlooked in the removal/restoration churn of implicit opening?

Is there something specific in the #1797 discussion that affects this? Nothing jumps out at me, though the overall thrust of weakening the STOP_SENDING restrictions is certainly related.

-- 
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/2345#issuecomment-455755429

---

From: MikkelFJ <[email-masked]>
Date: Sat, 19 Jan 2019 01:12:32 -0800

Please see my response here: https://github.com/quicwg/base-drafts/pull/2352#issuecomment-455762660

I don't object to the intention, I fact I seem to recall finding the original text overlooking this. But we just need to be careful 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/issues/2345#issuecomment-455763037

---

From: MikkelFJ <[email-masked]>
Date: Sat, 19 Jan 2019 01:42:11 -0800

The old and new text is based on the senders local created state.
But the peer cannot know the senders local state.

https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#fig-stream-send-states

The fact that a sender created a stream does not mean that the peer has the information yet. It cannot have that information before the highest numbered stream is beyond the READY state.

A peer could legally send STOP_SENDING if it has a out of band information about the senders state even if it is not permitted to send anything else.

The text should instead forbid a peer from sending STOP_SENDING on any stream that is not yet created at its end, meaning it has seen data from the same stream or a higher stream of same kind.

Also the sender should not accept STOP_SENDING unless the local stream state is beyond Ready, or a higher numbered stream of same kind is beyond Ready.

-- 
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/2345#issuecomment-455764961

---

From: MikkelFJ <[email-masked]>
Date: Sat, 19 Jan 2019 01:47:06 -0800

What makes this difficult is the remote initiated uni-streams do not have a created state in the same way a bidi-stream has. STOP_SENDING should behave the as if the stream was a bidi stream only be allowed send STOP_SENDING when it can send data on the reverse channel. But it doesn't make sense to say that for uni streams. This leads to assumptions on state at the wrong end of the connection.

-- 
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/2345#issuecomment-455765321

---

From: Benjamin Saunders <[email-masked]>
Date: Sat, 19 Jan 2019 10:28:06 -0800

Strictly speaking, the old and new text both dictate what conditions an error is generated by the endpoint receiving the frame, in which case it is entirely appropriate to rely on that endpoint's state. The conditions under which it's safe to send are only implied, but I suppose it wouldn't hurt to be explicit.

[§3.2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.3.2) dictates that a receive stream enters the Recv state when a higher-number stream is created. That suggests the following phrasing to me:

> STOP_SENDING MUST only be sent for streams in the Recv or Size Known states. Receiving a STOP_SENDING frame for a stream that is not yet created MUST be treated as a connection error of type STREAM_STATE_ERROR.

-- 
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/2345#issuecomment-455803860

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jan 2019 11:48:41 -0800

Closed #2345 via #2354.

-- 
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/2345#event-2089793913