Re: Unidirectional streams PR

[Mark Nottingham <[e-mail]>]

[ co-chair hat on ]

Everyone --

To add some context -- this is (obviously) a big change, so we've asked Martin to prioritise it so that people can give it due consideration early in the process, before people start implementing streams broadly.

As our charter says, "consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified." 

To get to that consensus in *either* direction, we need broad input on this, so please have a look through and express your support, concerns, etc. on-list. 

I'd like to see a substantial amount of on-list discussion before Prague, so that we can make a decision in that time frame.

Cheers,


> On 21 Jun 2017, at 5:41 pm, Martin Thomson <[e-mail]> wrote:
> 
> I've created a pull request unidirectional streams.
> 
> https://github.com/quicwg/base-drafts/pull/643
> 
> I won't go into detail about this here, other than to point out that
> there is extensive rationale for the choices I made in the PR summary,
> a copy of which I will include for your convenience.
> 
> ## Transport Changes
> 
> Streams are unidirectional.  Each has three states: idle, open, and
> closed.  I separated the transitions for sending and receiving because
> that turned out to be easier to explain.  The reordering thing makes
> them different in subtle ways.
> 
> That's all.  The changes in transport are relatively small and they
> simplify streams a lot.  That it also makes the transport more generic
> is a nice bonus.
> 
> ## HTTP Changes
> 
> This is where the bulk of the changes are.
> 
> ### Stream Correlation
> 
> Previously request and response were implicitly correlated, as was the
> data correlated with the request or response headers.  With this
> change, that correlation each stream has a header that explicitly
> correlates these.
> 
> There are 5 types of stream: connection control, request, response,
> data, and push.  The first two have a simple header that has a type.
> The next two reference another stream in their header, which ties
> request to response and data to request or response.  Push streams
> each reference a PUSH_PROMISE using a newly minted push ID (I decided
> that was cleaner than what I proposed at the interim).
> 
> I chose backward references rather than forward references for two
> reasons.  First, request and response correlation can't use forward
> references because that would mean the client would be exerting
> (uncoordinated) control over server streams.  Second, that gives the
> server the most flexibility in terms of how it answers requests (see
> #281).  The cost of using backward references is that endpoints have
> to check that the backward references aren't bad, either referencing
> the wrong type of stream, or with multiple references to the same
> stream.
> 
> The presence or absence of a message body is signaled after the
> initial header block using a HAS_BODY frame.  This empty frame
> indicates that another stream will include the body of the message -
> or a promise for a body.  I would like to eliminate this stream split.
> See #245 and #557 for more details on that, though we need to fix #176
> first, which brings us back to QPACK/QCRAM again.
> 
> ### Prioritization
> 
> This changes prioritization so that it identifies requests.  I only
> made the minimal changes here, which means that this doesn't fix #441
> at the same time, I've left that for later (see below).
> 
> ### Cancelling Pushes
> 
> Because server push doesn't create streams with PUSH_PROMISE, I had to
> create a way to cancel them between the time that the PUSH_PROMISE is
> sent and when the push stream is created.  That's called RST_PUSH.
> 
> ## Things That Need Improvement
> 
> I haven't based this on #171.  I think that functionality is good, but
> the last time I looked at the PR I didn't like some of the changes
> Mike made there.  (That's a taste thing.)  This really assumes that we
> accept something very much like #171.
> 
> This really needs QPACK/QCRAM.  Right now, it is impossible to cancel
> some types of request using RST_STREAM because not all messages will
> have a body (#176 again).  On balance, given that bodies are what you
> really want to kill, it's not disastrous, but it's a problem
> nonetheless.  I think that we all agree that this is something that we
> need to fix, but we haven't reached the point where we agree on the
> details of the fix.
> 
> ## Things That Want Improvement
> 
> This also really wants headers and data on the same stream .  It
> doesn't exactly need that, but merging the streams would make things a
> lot easy, both conceptually and structurally.
> 
> I chose the simplest possible encoding for all of the fields that I
> touched.  That means that stream IDs are all 32 bits in size and the
> HAS_BODY frame takes an entire 9 octets.  For things that are that
> common, there are many ways in which byte efficiency could be
> improved.
> 
> The push ID changes might allow us to trivially fix #441.  Use of an
> as-yet-not-created push ID as a node in the priority tree would allow
> for prioritization to use "empty" nodes.  We'd need to explicitly
> allow that though.
> 
> # Fixes
> 
> Closes #515, #240, #281, #175.
> 

--
Mark Nottingham   https://www.mnot.net/