Subject: [quicwg/base-drafts] HTTP/QUIC without Alt-Svc? (#253)

From: Mike Bishop <[email-masked]>
Date: Tue, 31 Jan 2017 13:06:15 -0800

While HTTP/QUIC doesn't formally require a client to implement Alt-Svc, there's no discovery mechanism other than Alt-Svc provided, so you're not going to get very far without it.  That makes a full HTTP(/TLS)/TCP stack mandatory simply to open the connection in the first place.  For various reasons (e.g. an embedded device in a controlled environment), a client might want to dispense with TCP altogether when it knows that the endpoint will support QUIC.  It might also be useful in testing to be able to directly reference a QUIC endpoint.

Should we mint new scheme(s) that allows direct reference to a resource served exclusively over HTTP/QUIC?

(Note, in HTTP/2 the answer was "no," because HTTP/2 could be negotiated using the same TCP connection.  QUIC doesn't have that luxury.)

-- 
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/253

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jan 2017 15:46:22 -0800

I'm thinking that the answer is "no" here as well.  Developing a way to provide supplementary annotations on links would be less reliable, but ultimately more likely to succeed.

-- 
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/253#issuecomment-276530620

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 31 Jan 2017 17:40:10 -0800

I agree with the opinions about new scheme(s). However, it does seem a shame to have this implicit dependency on Alt-Svc delivered by HTTP. By my understanding of Alt-Svc, the origin would have the requirement of offering resources via HTTP(/TLS)/TCP in perpetuity. That seems a bit unfair to me.

I recall some talk about TCP fallback (e.g. at the QUIC BoF IETF 96). No text currently in WG docs seem to require this though. the closest is in the HTTP/QUIC mapping:

```
Connectivity problems (e.g. firewall blocking UDP) may result in QUIC connection
establishment failure, in which case the client should gracefully fall back to
HTTP/2.
```

If TCP fallback is not actually required, and a solution can be found to directly open QUIC connections then there is a route to deprecate HTTP(/TLS)/TCP. Similarly, constrained devices that want to operate without HTTP(/TLS)/TCP could do so, bearing the risk of %N connection failure rate.
----

Forgive this stupid question: is there text somewhere in an RFC that requires a client accessing resources with a `https` scheme to use TCP? I appreciate the scheme is described in terms of TCP and port 443 but wonder if  there is anything preventing a client from trying their luck on opening a QUIC connection whenever it sees a `https` scheme? ( a more sensible whitelist approach could also be taken). Perhaps this is more suited to an implementation debug feature, which supports Mike's testing ideas.

----

Forgive this other stupid question: what about other application-layer protocols over QUIC? Do they also have an implicit dependency on Alt-Svc, or is that totally inappropriate?

-- 
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/253#issuecomment-276549420

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jan 2017 17:56:39 -0800

Other protocols have their own bootstrapping problems.  Too much depends on context to be sure.  For instance, migrating something like FTP might be tricky and something akin to Alt-Svc might be the most practical approach.  On the other hand, migrating RTP probably won't have problems in this area because it uses a signaling protocol for setup (RTP would have a host of other problems, of course).

-- 
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/253#issuecomment-276551881