Subject: Re: [quicwg/base-drafts] Resume HTTP/2 TLS from QUIC ? (#941)

From: martinduke <[email-masked]>
Date: Fri, 05 Oct 2018 15:57:23 -0700

What would be the impact of changing the hq ALPN value to h2? Whatever we call it, it's basically HTTP/2 for QUIC, and on a QUIC connection there's no ambiguity as to what the client is asking for.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/941#issuecomment-427519947

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 06 Oct 2018 07:35:58 -0700

At a conceptual level, we'd be defining the hq ALPN ID for Alt-Svc, that is never used for TLS ALPN :)

I guess this might come down to how implementations support mixed application layer protocols. I might build a dispatcher that operates on the protocol decided by TLS ALPN, deciding whether to invoke H2 or HQ handshake code. 

Right now, QUIC operates over UDP but I'd like to think we build HTTP over QUIC implementations that are functional any knowledge of the protocol under QUIC (e.g. QUIC over CAN bus).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/941#issuecomment-427578506

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Oct 2018 23:07:01 -0700

> What would be the impact of changing the hq ALPN value to h2? 

Everything breaks, as 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/941#issuecomment-428449173

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Oct 2018 23:07:01 -0700

Closed #941.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/941#event-1894585010

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Oct 2018 23:07:05 -0700

Reopened #941.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/941#event-1894585129

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Oct 2018 23:08:15 -0700

> What would be the impact of changing the hq ALPN value to h2? 

Everything breaks, as @LPardue describes.  I think that there is a way to do this, but we would need new signaling for alt-alpn.  I don't want to embark on that effort right now.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/941#issuecomment-428449428

---

From: martinduke <[email-masked]>
Date: Mon, 15 Oct 2018 09:30:43 -0700

> Right now, QUIC operates over UDP but I'd like to think we build HTTP over QUIC implementations that are functional without any knowledge of the protocol under QUIC (e.g. QUIC over CAN bus).

As defined in the spec, QUIC operates over UDP. The question, as I see it, is if servers are able to demultiplex an incoming connection to the correct TLS and application. It's evident to me that we can demultiplex on the protocol number (or, the protocol of the listening socket, if we don't have access to IP header contents).

This helps solve an immediate problem with adoption. I'm not sure that QUIC-over-something-weird is in the same class. If this is the only issue, we can always switch the ALPN code in v2 to support more complicated use cases, once browsers are routinely trying QUIC when they connect.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/941#issuecomment-429923070

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 15 Oct 2018 16:56:38 +0000 (UTC)

I'm a bit confused which point your addressing @martinduke, my fault for throwing stupid ideas in. Is your line of thought that a dispatcher would two classes {h2, TCP} and  {h2, UDP} to make the decision. Exposing the protocol information seems like some layering leakage to me, but it is powerful so maybe warrants it?

The mismatch between advertising `hq` and then using `h2` seems like an avenue for interop issues. Perhaps one could define an Alt-Svc param that indicates the protocol type e.g. `Alt-Svc: h2=":443"; proto=udp`. A bog-standard HTTP/2 client would simply ignore the param and try TLS/TCP.

P.S. From direct experience, I've had quite a lot of success delivering QUIC wire-format packets in all sorts of weird ways and our HTTP/QUIC layer of code works amazingly well because it doesn't care how they were delivered.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/941#issuecomment-429931699

---

From: martinduke <[email-masked]>
Date: Mon, 15 Oct 2018 11:42:46 -0700

Please, I'm the one messing with stuff I barely understand. What I was missing is that the alt-svc name is the same as the ALPN name. Yes, that makes this quite difficult without rewriting other RFCs. Grrr.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/941#issuecomment-429968764