Re: Unidirectional streams PR

[Martin Thomson <[e-mail]>]

On 22 June 2017 at 09:48, Jana Iyengar <[e-mail]> wrote:
> 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.

I think that this is a fair criticism, and I wanted to address it.

My concern is exactly the same as yours: I want get HTTP working.  And
unfortunately, HTTP/2 is not a simple request/response protocol.  This
is why HTTP/2 and now QUIC allow the server to initiate streams.  And
it's that exact gap that motivated me to propose this change.  In my
view, this change makes it *easier* to finish HTTP over QUIC.

The cost is that HTTP is marginally more complex.  My view is that the
overall protocol (HTTP+QUIC) is no more or less complex than before,
there are big savings in transport, and some minor savings in HTTP
that counteract the added cost: having to include explicit correlation
for request and response, and having to add a way to cancel requests
before the response starts. [1]

In terms of generality, we've already heard from Christian that this
is basically neutral for DNS, possibly with a tiny reduction in
complexity related to not having to check that redundant identifiers
in a response are consistent.

Ted suggested that we aim for a design that supports BOTH
unidirectional and bidirectional. Given how trivial it is to add an
identifier - as demonstrated by this PR - I don't see how building
that facility into the base transport is a net win.  Some protocols
can still use the stream identifiers as a correlator, for instance
those protocols that are properly request/response don't need explicit
correlators.  That choice - as with your proposal to retain
bidirectionality - creates a potential for head-of-line blocking under
certain circumstances, something that an explicit correlator at the
application layer neatly avoids.

[1] I don't consider HAS_BODY to be a cost, I'm now firmly of the
opinion that merging headers and body back into a single stream is the
right solution and that what I wrote up here is only temporary.