RE: HTTP/QUIC Diverging from HTTP/2

I’d question anyone who told you the road from initial proposal (SPDY) to final standard (HTTP/2) over the course of multiple years would be “just a few refinements.” That said, our implementation of HTTP/2 did start with an implementation of SPDY/3, then evolved to match the HTTP/2 implementation drafts as they were published, so I understand the pain of architectural changes as the draft evolves.  I do hope people will be doing the same with HTTP/QUIC. It’s an iterative process, and we need implementer feedback to make those refinements.

FWIW, I don’t see either as being a “transport for HTTP/1”.  HTTP/1.1, HTTP/2, and HTTP/QUIC are mappings of the same HTTP semantics to different transports – the first two to TCP, the second to QUIC.  The same HTTP semantics should apply to all three.  Server Push is the only really “new” semantic for HTTP/2, and even that manages to fit the HTTP request/response model by having the server propose a request.

But yes, QUIC has the complexity of a new transport – you’re implementing an alternative to TCP before reimplementing an HTTP mapping on top of it.  That mapping should be much lighter-weight than HTTP/2 because much of what HTTP/2 builds out is now provided by QUIC, but first you have to build QUIC, and in these early drafts it’s changing rapidly.

From: Alcides Viamontes E [mailto:alcidesv@shimmercat.com]
Sent: Thursday, March 9, 2017 11:19 AM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: quic@ietf.org; HTTP working group mailing list <ietf-http-wg@w3.org>
Subject: Re: HTTP/QUIC Diverging from HTTP/2

Hello Mike,

I have server implementations of SPDY and then later HTTP/2, which was supposed to be very close to SPDY with just a few refinements. Well it turned out that these "minor refinements" of HTTP/2 required a completely different software architecture. If I had known from the outset that HTTP/2 was that different from SPDY, I could have saved some time by implementing HTTP/2 from scratch on first instance.

We have also considered to implement QUIC for a time, but the protocol and the draft describing it look quite complex, and this thing of QUIC being a transport for HTTP/2 being a transport for HTTP/1 doesn't make it easier. So my dream scenario would be to have a standard which only mentions HTTP/2 in passing. Of course QUIC being a transport for HTTP/1 semantics is completely acceptable and to a point, expected.




On Thu, Mar 9, 2017 at 7:53 PM, Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>> wrote:
At Patrick’s suggestion, I’m restating this question and addressing it to both the HTTP and QUIC working groups.  Apologies if you’re already following along in QUIC and get this twice after having already seen it the first time.

HTTP/QUIC started off (draft -00) with a mostly-complete HTTP/2 session on QUIC Stream 3, including a full HTTP/2 multiplexing layer within Stream 3.  A number of HTTP/2 frames weren’t necessary, since they were duplicative of services QUIC provides.  In draft -01, we removed the full mux layer from Stream 3, instead letting QUIC deal with all the stream management.  This necessitated changes to several of the remaining frames.  By the current editor’s copy, no HTTP/2 frame exists unmodified in HTTP/QUIC, though several frames of the same name and purpose exist.  Likewise, RFC7540 defines six settings, three of which are inapplicable in HTTP/QUIC.

However, the draft currently still attempts to define them as close cousins.  It updates the HTTP/2 frame and setting registries with additional columns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Specification if applicable) and attempts to coexist with HTTP/2 in the same registry.  (QUIC defines a unified error space, which means a separate registry of error codes for HTTP/QUIC regardless.)

In PR #363<https://github.com/quicwg/base-drafts/pull/363>, I’ve consolidated almost all of the “different from HTTP/2” text into a new top-level section and excised a lot of “HTTP/2 has this, but HTTP/QUIC doesn’t need it” text from the main body of the document.  Martin has advocated making a clean break from HTTP/2 and defining our own IANA registry for frame types and settings, just as we already have for errors.  We can, out of respect for our cousin, use the same values where appropriate and reserve existing values currently in use on the HTTP/2 side.

I think that’s a good idea, and it’s a fairly small step from the current state of #363.  I’ve created PR #376<https://github.com/quicwg/base-drafts/pull/376> to actually make that split.

Comments from both WGs about the two PRs would be welcome.  (Feedback so far from the QUIC side seems to mostly be “separate with regrets,” but not universally.)



--
Alcides Viamontes E.
Chief Executive Officer, Zunzun AB
(+46) 722294542
(www.shimmercat.com<http://www.shimmercat.com> is a property of Zunzun AB)