Re: Unidirectional streams PR

["Philipp S. Tiesel" <[e-mail]>]

> On 22. Jun 2017, at 03:50, Martin Thomson <[e-mail]> wrote:
> 
> 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]

> [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.

I have some concerns here, as separating the body into a different stream
allows more flexible design later on: If we added unreliable transport to
quick, having the header sent reliably and the body unreliably seems useful.

Canceling the stream is still possible if a) the stream ID is known by
convention or b) the stream ID is provided in a forward-reference.


> 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.

I guess having a OPEN_STREAM frame that allows to associate a new steam
to a stream in reverse direction and thus building a a bi-directional
stream pair is a good compromise as it allows bi-directinal streams in
a quic API without introducing additional state space in the base protocol.


AVE!
  Philipp S. Tiesel / phils…