Subject: HTTP/QUIC Diverging from HTTP/2

From: Mike Bishop <[email-masked]>
Date: Thu, 9 Mar 2017 18:53:32 +0000

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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 9 Mar 2017 21:18:46 +0000

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:[email-masked]]
Sent: Thursday, March 9, 2017 11:19 AM
To: Mike Bishop <[email-masked]>
Cc: [email-masked]; HTTP working group mailing list <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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.

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)

---

From: Mike Bishop <[email-masked]>
Date: Fri, 10 Mar 2017 02:09:57 +0000

Summary of feedback on this so far:

  *   Ekr:  "Hoping we can converge, or at least maximize overlap"
  *   Stefan:  "any hope to [converge] needs to be abandoned"
  *   Ian:  "not excited... but it may... be the right thing to do"
  *   Patrick:  "separate protocols"
  *   Martin:  "keep the differences minimal" but "we're really building a new protocol"
  *   Alcides:  if it's different, make the differences clear

If I've misconstrued anyone's response, please speak now; and obviously, more opinions are welcome.  I would also appreciate reviews on the text of the PRs themselves.

Unless there's strong pushback in the next ~14 hours, I expect to incorporate both PRs tomorrow, prior to the -02 publication.  As Mark noted recently, that doesn't claim full consensus has been reached, but there appears to be general support for considering these separate protocols which are closely related, rather than two variants of a single protocol.

From: Mike Bishop
Sent: Thursday, March 9, 2017 10:54 AM
To: [email-masked]; HTTP working group mailing list <[email-masked]>
Subject: HTTP/QUIC Diverging from HTTP/2

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Mar 2017 18:27:58 -0800

On Thu, Mar 9, 2017 at 6:09 PM, Mike Bishop <[email-masked]>
wrote:

>    - Ekr:  “Hoping we can converge, or at least maximize overlap”
>    - Stefan:  “any hope to [converge] needs to be abandoned”
>    - Ian:  “not excited… but it may… be the right thing to do”
>    - Patrick:  “separate protocols”
>    - Martin:  “keep the differences minimal” but “we're really building a
>    new protocol”
>    - Alcides:  if it’s different, make the differences clear
>
>
>
> If I’ve misconstrued anyone’s response, please speak now; and obviously,
> more opinions are welcome.  I would also appreciate reviews on the text of
> the PRs themselves.
>
>
>
> Unless there’s strong pushback in the next ~14 hours, I expect to
> incorporate both PRs tomorrow, prior to the -02 publication.  As Mark noted
> recently, that doesn’t claim full consensus has been reached, but there
> appears to be general support for considering these separate protocols
> which are closely related, rather than two variants of a single protocol.
>
>
>

This seems like pretty weak consensus, so I'd prefer we discuss this in ORD
rather than
having you merge this now.

-Ekr

*From:* Mike Bishop
> *Sent:* Thursday, March 9, 2017 10:54 AM
> *To:* [email-masked]; HTTP working group mailing list <[email-masked]>
> *Subject:* HTTP/QUIC Diverging from HTTP/2
>
>
>
> 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.)
>

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 9 Mar 2017 20:33:05 -0800

On Thu, Mar 9, 2017 at 6:09 PM, Mike Bishop <[email-masked]>
wrote:

> incorporate both PRs tomorrow, prior to the -02 publication.  As Mark
> noted recently, that doesn’t claim full consensus has been reached, but
> there appears to be general support for considering these separate
> protocols which are closely related, rather than two variants of a single
> protocol.
>
>
​For the record, I agree with ekr. As much as possible, let's be similar to
HTTP/2. Of course, QUIC natively provides multiplexing but does not provide
in-order delivery. As a consequence, HTTP over QUIC will have differences.​
But where we have the opportunities to overlap, that sounds desirable.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 10 Mar 2017 06:24:36 +0000

--------
In message <[email-masked].
outlook.com>, Mike Bishop writes:

>but there appears to be general support for considering these separate
>protocols which are closely related, rather than two variants of a
>single protocol.

If so, it would be incredibly short-sighted to not take the chance
to drop some of the worst bogons overboard while you have the
chance.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Alcides Viamontes E <[email-masked]>
Date: Thu, 9 Mar 2017 20:18:49 +0100

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.

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

---

From: Cory Benfield <[email-masked]>
Date: Fri, 10 Mar 2017 08:39:02 +0000

> On 10 Mar 2017, at 02:09, Mike Bishop <[email-masked]> wrote:
> 
> 	• Ekr:  “Hoping we can converge, or at least maximize overlap”
> 	• Stefan:  “any hope to [converge] needs to be abandoned”
> 	• Ian:  “not excited… but it may… be the right thing to do”
> 	• Patrick:  “separate protocols”
> 	• Martin:  “keep the differences minimal” but “we're really building a new protocol”
> 	• Alcides:  if it’s different, make the differences clear
>  
> If I’ve misconstrued anyone’s response, please speak now; and obviously, more opinions are welcome.  I would also appreciate reviews on the text of the PRs themselves.
>  
> Unless there’s strong pushback in the next ~14 hours, I expect to incorporate both PRs tomorrow, prior to the -02 publication.  As Mark noted recently, that doesn’t claim full consensus has been reached, but there appears to be general support for considering these separate protocols which are closely related, rather than two variants of a single protocol.

FWIW, I’m somewhere in between Ekr and Stefan. I think that where possible overlap and convergence should be pursued, but I don’t think we should hold our breaths. Ultimately I think in software implementations there will be very little common code between HTTP/2 and QUIC: barely any more than there is between HTTP/1.1 and HTTP/2, and potentially less. That suggests that HTTP/2 and QUIC are no more closely related to each other than HTTP/2 is to HTTP/1.1.

That sounds to me like “close cousins, but different protocols”.

Cory

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 10 Mar 2017 12:14:27 +0000

FWIW, my opinion as "not an implementer".

I support a clean break.

The background thinking on my part has been in relation to the ALTSVC extension frame, and where its registration should be defined. An independent HTTP/QUIC frame type table (that ports over the non-extension RFC 7540 frame types) simplifies this problem, shifting the responsibility to the extension documents (or their updates). As others have pointed out, there may be a burden with the single table approach of requiring new HTTP/2 extensions to consider HTTP/QUIC.

I'd also say ALTSVC is a good case study for another reason. It defines a new HTTP semantic that is mapped to both an HTTP Header Field and an HTTP/2 extension frame, which are registered differently.

The one risk with separate tables is that the Frame type codes diverge over time. A pragmatic mitigation might be to reserve the code in both tables, even if this is a placeholder for future work.

In considering this topic, I was reminded of Mike's earlier work on decomposing HTTP, captured in the I-D draft-bishop-decomposing-http<https://tools.ietf.org/html/draft-bishop-decomposing-http-01>.

Lucas

From: QUIC [mailto:[email-masked]] On Behalf Of Mike Bishop
Sent: 09 March 2017 18:54
To: [email-masked]; HTTP working group mailing list <[email-masked]>
Subject: HTTP/QUIC Diverging from HTTP/2

---

From: Mike Bishop <[email-masked]>
Date: Fri, 10 Mar 2017 17:20:14 +0000

I’m fine holding off on the second PR that actually does the split, if you want.  The first PR resolves an issue (need advice on mapping HTTP/2 extensions) and is mostly editorial beyond that, so I’m planning to merge that one unless you object specifically to it.

From: Eric Rescorla [mailto:[email-masked]]
Sent: Thursday, March 9, 2017 6:28 PM
To: Mike Bishop <[email-masked]>
Cc: [email-masked]; HTTP working group mailing list <[email-masked]>
Subject: Re: HTTP/QUIC Diverging from HTTP/2

On Thu, Mar 9, 2017 at 6:09 PM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
Summary of feedback on this so far:

  *   Ekr:  “Hoping we can converge, or at least maximize overlap”
  *   Stefan:  “any hope to [converge] needs to be abandoned”
  *   Ian:  “not excited… but it may… be the right thing to do”
  *   Patrick:  “separate protocols”
  *   Martin:  “keep the differences minimal” but “we're really building a new protocol”
  *   Alcides:  if it’s different, make the differences clear

This seems like pretty weak consensus, so I'd prefer we discuss this in ORD rather than
having you merge this now.

-Ekr

From: Mike Bishop
Sent: Thursday, March 9, 2017 10:54 AM
To: [email-masked]<mailto:[email-masked]>; HTTP working group mailing list <[email-masked]<mailto:[email-masked]>>
Subject: HTTP/QUIC Diverging from HTTP/2