Subject: [quicwg/base-drafts] Move stream close forward (#628)

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jun 2017 07:07:23 -0700

With MAX_STREAM_ID, the need to delay stream close is less needed.  We no longer need to track closed in order to support enforcing of the concurrent stream limit.  Endpoints can provide or withhold new stream identifiers as they are able or see fit.

This removes some of the pressure to choose a very late point in time to move to the closed state.  In fact, Google's QUIC implementation doesn't track state for streams past the point that all data is first sent.  Waiting for acknowledgment in that implementation is managed by a connection-level construct.

Making streams close on sending means that the state machine is simpler to explain.

Or, we could consider adding a state for the case where streams are draining.

-- 
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/628

---

From: janaiyengar <[email-masked]>
Date: Tue, 13 Jun 2017 08:31:47 -0700

I don't think it makes sense for streams to be draining... the connection ought to handle that, IMO. (I'll check what GQUIC does and get back on when we close streams. The constraints are different though, since open streams in GQUIC count towards MAX_OPEN_STREAMS, whereas with QUIC we now don't have that trouble.)

-- 
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/628#issuecomment-308155865

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jun 2017 09:46:54 -0700

Closed #628.

-- 
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/628#event-1121761717

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jun 2017 09:46:55 -0700

Well, the nice thing about having a maximum stream ID is that it might not even matter how we define the stream states and closing behaviour.  We might just make a comment that the stream state is advisory.  In any case, this was resolved in one way in the current draft.  I intended to close this immediately, but forgot.  So here goes.

-- 
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/628#issuecomment-308178192