RE: Unidirectional streams PR

[Mike Bishop <[e-mail]>]

As we've discussed, I highly approve moving in this direction, and this PR looks like a solid way of doing it.  Review with a few comments, but nothing I'd scream about.

I'll second Martin's opinion -- this doesn't make HTTP/QUIC noticeably more complex.  What it does, and what I suspect gives some people heartburn, is make it *less like HTTP/2*.  The more code reuse you thought you were going to be able to do, the more this makes you unhappy.  This also makes it less like TCP; in a way that's simple for a mapping to deal with, but it means the mapping actually needs thought.  (That's not entirely a bad thing.)

I've said it before, and I'll probably keep saying it:  HTTP/QUIC is not just HTTP/2 over QUIC.  It's similar in spirit, but QUIC is fundamentally different and HTTP/QUIC has to follow.  I'm all for code reuse where feasible, and concept reuse as broadly as possible, but let's not get stuck on net-positive changes because they're different from our existing code (QUIC *or* HTTP/2).

-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Martin Thomson
Sent: Wednesday, June 21, 2017 6:50 PM
To: Jana Iyengar <[e-mail]>
Cc: QUIC WG <[e-mail]>; Patrick McManus <[e-mail]>
Subject: Re: Unidirectional streams PR

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.