Re: Unidirectional streams PR

[Jana Iyengar <[e-mail]>]

Thanks for writing up the PR, Martin. It does help to see the details laid
down. I have a few thoughts.

First, there are issues that unidirectional streams raises, some of which
we can articulate, and some which we don't know yet simply because we have
no production experience with them.

In the former category, here's an issue that isn't handled right now.
Google maps uses map-tiles for displaying parts of mapped region. As a user
moves to a different region, the client cancels all pending requests, since
those map-tiles are no longer relevant and those responses are no longer
needed. Let's say that the requests were completely sent (FIN and all), but
the responses hadn't started yet. In the bidirectional world, a client
would achieve this by sending a RST_STREAM on all streams that have
responses pending, causing the server to send a RST_STREAM back. In the new
world, the client would have no way of canceling a pending request until
the server started responding. (And right now in your PR, I don't think
there's a way for an endpoint to RST a peer-initiated stream.)

Of the issues we don't know about yet, we'll only know with deployment
experience. I'm wary of standardizing something where we have no deployment
experience, no production experience. (Server Push is an overused but
classic example of this: it was standardized before there was any
significant deployment experience, and we continue to struggle with
actually deploying it. Also, see HTTP/2 Priorities.)

Second, your key premise is that unidirectional streams makes transport
logic simpler. I agree with that, and the PR clearly simplifies the
transport stream machinery. However, HTTP requires bidirectional streams,
and this PR moves that complexity to HTTP. This is useful if HTTP were the
only application that did request-response, but request-response is an
incredibly common design pattern, and one that is naturally facilitated by
bidirectional streams. Making every application reimplement bidirectional
streams atop QUIC's unidirectional streams *adds* complexity overall. My
design sense says to optimize for the common case and to allow for the
exceptions. Given that our scope is to really get things rolling for HTTP
ASAP, I'd argue that request-response is the common case that we need to
optimize for.

This PR makes it even clearer to me that we need deployment experience with
unidirectional streams before going down this path. We have that with
bidirectional streams, which makes it worth standardizing.

To be clear, I'm not saying that unidirectional streams aren't interesting.
FWIW, the original input draft
<https://www.ietf.org/archive/id/draft-hamilton-quic-transport-protocol-01.txt>,
which is still how GQUIC works right now, has app read_close and
write_close transitions in the stream state machine which would allow a
stream to become unidirectional, but the application endpoints have to know
that these streams are unidirectional. We can explicitly specify a separate
bit in the STREAM frame that indicates uni/bi-directional stream, allowing
for unidirectional streams as "always half-closed" (bidirectional) streams.
Implementations can obviously optimize code for uni streams separately, but
the spec would be straightforward. I'm happy to write this up as an
alternative, since I think this is valuable.

- jana



On Wed, Jun 21, 2017 at 2:48 AM, Patrick McManus <[e-mail]>
wrote:

> I have come to strongly support unidirectional streams. I'm writing
> because I think we can take this just a tiny bit further and get a pretty
> big architectural win.
>
> the PR adds a stream-header to the http mapping.. a key feature of that is
> a few bytes indicating what stream # a reply (or a push, etc..) is
> associated with because its not implicit in the stream # anymore. I love
> the removal of some transport IDs from the HTTP mapping.
>
> If we take that just a touch further and include this label explicitly in
> the request as well then there is no reason to require the use of transport
> stream ids  for the labeling at all (though you could!) - and now you can
> imagine quic http being implemented on a quic transport api that looks a
> lot like existing transport apis without having to resort to inventing
> something like quic_getpeerstreamid().
>
> Relatedly the mapping defines a very short stream header to identify the
> control channel  so I don't think there is any reason to lock it onto
> stream 1 (and let the transport-id leak into the application mapping in the
> process). Its not like putting it on stream 1 guarantees it will arrive
> first anyhow.
>
> -Patrick
>
>
> On Wed, Jun 21, 2017 at 8:41 AM, 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.
>>
>>
>