Subject: Re: HTTP/QUIC Diverging from HTTP/2

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 10 Mar 2017 02:59:52 +0000

Hi Mike

for the benefit of those of us who maybe aren't so familiar with QUIC, 
are there any good resources you can refer us to which deal with the 
bigger picture such as why even have QUIC?

So far our experience with QUIC (as a proxy) has been to simply block 
it, since it provides a bypass mechanism for proxy control.

Regards

Adrien

------ Original Message ------
From: "Mike Bishop" <[email-masked]>
To: "[email-masked]" <[email-masked]>; "HTTP working group mailing list" 
<[email-masked]>
Sent: 10/03/2017 3:09:57 PM
Subject: RE: HTTP/QUIC Diverging from HTTP/2

>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
>
>
>
>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: Martin Thomson <[email-masked]>
Date: Fri, 10 Mar 2017 14:12:48 +1100

On 10 March 2017 at 13:59, Adrien de Croy <[email-masked]> wrote:
> for the benefit of those of us who maybe aren't so familiar with QUIC, are
> there any good resources you can refer us to which deal with the bigger
> picture such as why even have QUIC?

This probably isn't the place for that discussion.  I would recommend
reading the drafts.  They aren't complete, but you will gain some
appreciation for what is going on.  Think about this in terms of
replacing TCP, not HTTP.  There are higher level things around, like
this old presentation:
https://docs.google.com/presentation/d/1T9GtMz1CvPpZtmF8g-W7j9XHZBOCp9cu1fW0sMsmpoo

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 10 Mar 2017 03:19:07 +0000

thanks for that.

Yes, the whole meta discussion about why / benefits etc can influence 
adoption pressure, and decisions around whether we should support it or 
block it.

Cheers

Adrien

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Mike Bishop" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "HTTP working group mailing list" <[email-masked]>
Sent: 10/03/2017 4:12:48 PM
Subject: Re: HTTP/QUIC Diverging from HTTP/2

---

From: Andy Green <[email-masked]>
Date: Fri, 10 Mar 2017 11:25:02 +0800

On 03/10/2017 11:19 AM, Adrien de Croy wrote:
> adoption pressure, and decisions around whether we should support it 
> or block it.

If I can run websockets over it, it will already be more useful than 
http/2 for me...

-Andy

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 10 Mar 2017 08:36:11 +0100 (CET)

On Fri, 10 Mar 2017, Andy Green wrote:

> If I can run websockets over it, it will already be more useful than http/2 
> for me...

I've not seen anyone speak up about websockets for QUIC so I'd say the 
situation there is equal to h2: needing people to actively work on it or it 
won't happen.

(and I'm sure someone can/will correct me if I'm wrong)

-- 

  / daniel.haxx.se