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

From: ekr <[email-masked]>
Date: Sun, 27 Jan 2019 22:23:59 -0800

@martinthomson asked me to discuss here. There's no reason why clients shouldn't be able to just try QUIC with any server (a la Happy Eyeballs) without alt-svc.

-- 
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-458011576

---

From: Mike Bishop <[email-masked]>
Date: Sun, 27 Jan 2019 22:38:03 -0800

By that logic, why can't you just try https:// for any http:// URL, or try https://host:443/ if connecting to https://host:8443/ fails?  An origin specifies a scheme, protocol, and port; scheme by definition bundles a transport protocol.  If you change any of those, you're talking to a different origin.  Alt-Svc provides a mechanism for an origin to bless a different endpoint as being co-authoritative for that origin, and that's what H3 does currently.  Lacking an Alt-Svc delegation, you're talking to a different origin.

Now, if we chose to go update the definition of the "http" and "https" schemes to specify either/both transport protocols, we could perhaps do so; while it stretches the spirit of RFC 3986, that doesn't *exactly* say that it can specify only one transport protocol.

-- 
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-458014085

---

From: ExE Boss <[email-masked]>
Date: Sun, 27 Jan 2019 22:40:33 -0800

And that’s why we&nbsp;should use UDP&nbsp;port&nbsp;443 for&nbsp;HTTP/QUIC (as&nbsp;QUIC uses portions of&nbsp;TLS to do the encryption, and so HTTP/QUIC is&nbsp;HTTPS over&nbsp;UDP, which is&nbsp:what UDP&nbsp;port&nbsp;443 is&nbsp;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/253#issuecomment-458014531

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Mon, 28 Jan 2019 01:58:23 -0800

We had a similar discussion in TAPS and our drafts include some discussion on transport option gathering and racing (https://taps-api.github.io/drafts/draft-ietf-taps-impl.html).
I like to call this "Happy Eyeballs on Steroids" and the major problem that arises from racing between the combinations of  multiple IP versions (v4vs. v6), transports (TLS over TCP vs QUIC over UDP) and access networks/ PvDs (WiFi vs. Wired vs. LTE) is the state explosion you run into if you want to race for all of them. We solve this in TAPS by delaying the racing of less-preferred or less-likely candidates.

In my opinion, do a "Happy Eyeballs on Steroids" racing of HTTP/QUIC against HTTP/TLS is fine as long as the implementations make sure not to try all combinations on all connection attempts. This can be easily solved  by a combination of caching results results (try QUIC in a race if have seen an Alt-Svc announcement or is has worked in the past), well-chosen timings and probabilistic choice of what to probe.

-- 
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-458064699

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 29 Jan 2019 20:56:17 -0800

Using connection-establishment racing as a way to try out QUIC, while still falling back to TLS/TCP in a reasonable amount of time, is certainly a useful strategy and one that I'd like to promote for clients capable of techniques like Happy Eyeballs.

As @philsbln mentions, the key caveat here is that simultaneous racing is almost never the right answer. Ideally, you'd pick your preference (QUIC?) and then only start attempts for other endpoints/protocols/paths around the same time that the transport protocol would be doing its retransmission.

Even when you do have Alt-Svc telling you that an HTTP endpoint is HTTP/3 (and thus, QUIC) capable, being able to quickly fall back to HTTP/2 using this Happy Eyeballs approach is a benefit. This is to some degree a requirement to not fail on the <10% of networks that mistreat UDP traffic. So, racing is a technique that goes beyond discovery.

Using racing as a way to discover that an endpoint supports QUIC, as @ekr brings up, is certainly interesting. It's nicely generic, doesn't require changing lots of application protocols, and can allow clients to tune how optimistic they are about QUIC. You could imagine only trying QUIC first every so often, such that the user wouldn't notice the cases in which you'd need to wait the extra RTT before TLS/TCP is attempted in case QUIC is not supported. As QUIC becomes more widely deployed, it would make sense to try it more often. And, as a client learns which endpoints support QUIC, it can remember this to influence future decisions.

The main sticking point is knowing which port to use. Protocols other than HTTP that start being able to run over QUIC may have it in their best interests to define a well-known port to make this possible. The current HTTP spec that uses Alt-Svc is quite clear that the port may be anything. So, a client cannot *know* what port to try to optimistically race over until it connects over HTTP/2. Once it does get Alt-Svc, it can start racing connections after that.

However, if in deployment, we see a common pattern of HTTP/3 servers squatting on a certain UDP port (say, 443), then it may be in clients' best interests to try connecting to that port slightly ahead of an HTTP/2 attempt if they believe that QUIC is indeed preferable. That likely won't happen until we see pretty widespread deployment, but it is a reason to start solidifying some of the mechanisms for identifying or defining ports without needing a TCP connection.

-- 
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-458811958

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 29 Jan 2019 21:10:03 -0800

I have concerns about how happy eyeballs plays out for HTTP connection coalescing. I think it can be specified in a way that resolves my concerns, and defining such guidance is crucial for making coalescing feasibly deployable.

-- 
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-458814047

---

From: MikkelFJ <[email-masked]>
Date: Tue, 29 Jan 2019 22:06:39 -0800

How about making a solid DNS convention for alt-svc? If you use IP address directly, you probably also have port and protocol.

________________________________
Fra: Lucas Pardue <[email-masked]>
Sendt: onsdag, januar 30, 2019 6:10 AM
Til: quicwg/base-drafts
Cc: Subscribed
Emne: Re: [quicwg/base-drafts] HTTP/QUIC without Alt-Svc? (#253)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/253#issuecomment-458814047>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AALzN3FmTplyBmLtvkoYZf4EVQmE6EgRks5vISkpgaJpZM4LzLA5>.

-- 
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-458823877

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 29 Jan 2019 22:11:41 -0800

@mikkelfj do you mean the ALTSVC DNS record as proposed by Mike's I-D?

-- 
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-458824812

---

From: MikkelFJ <[email-masked]>
Date: Wed, 30 Jan 2019 00:05:37 -0800

I have not studied Mike's I-D (but I should take a look). I'm not concerned about the details, just that it DNS becomes the "normal" way to do resolve such things. SRV has had a history of being ignored in a chicken and egg fashion.

Also note that DNS could include supported versions.

-- 
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-458849080

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 30 Jan 2019 00:19:33 -0800

Link to I-D for reference https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02

Idea is that all information defined for HTTP/ alt svc would appear in that record

-- 
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-458852768

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Wed, 30 Jan 2019 02:01:39 -0800

@mikkelfj Putting the information whether QUIC is available in an ALTSVC DNS record does not eliminate the need for using Happy Eyeballs: If UDP to the announced port is blocked for the client, the client has to timeout otherwise. Still, having an ALTSVC DNS record would help to correctly tune the timings and probing probabilities for Happy Eyeballs.

@LPardue I see no problems with combining Happy Eyeballs and connection coalescing, but the relationship between them should really be defined somewhere. For me, connection coalescing opportunities are roughly the same thing as candidates for doing Happy Eyeballs, and should get as such at least 1 RTT advantage. So, in practice, try whether connection coalescing works, it it is slow or is behaving strangely, start making new connections with Happy Eyeballs.

-- 
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-458884416

---

From: ExE Boss <[email-masked]>
Date: Wed, 30 Jan 2019 02:27:37 -0800

I was thinking about a QUIC preload list, but putting Alt&#x2011;Svc into DNS works too.

Also, it might be a good idea to put HSTS into DNS too, since the HSTS preload list won’t scale well, but that’s a separate proposal.

-- 
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-458892733

---

From: MikkelFJ <[email-masked]>
Date: Wed, 30 Jan 2019 02:51:52 -0800

Having skimmed the ALTSVC DNS I-D, my only immediate concern is that it would probably be cumbersome for administrators to type ALTSVC into your typical DNS admin panel, whereas TXT would be easy, if the format is readable.

-- 
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-458900442

---

From: MikkelFJ <[email-masked]>
Date: Wed, 30 Jan 2019 03:07:21 -0800

>  ALTSVC DNS record does not eliminate the need for using Happy Eyeballs

Maybe not, but it does eliminate the need to wait for an Alt-Svc header response where there might not be an endpoint listening on tcp port 80, or the client does not have a TCP stack.

-- 
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-458905169

---

From: MikkelFJ <[email-masked]>
Date: Wed, 30 Jan 2019 03:10:32 -0800

Maybe ALTSVC is a bit misleading, if QUIC goes on to be a primary service rather than an alternative to something existing. I would be better if QUIC HTTP/3 could announce itself on neutral ground, although I agree that strong interop with current HTTP is important.

-- 
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-458906041

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 30 Jan 2019 03:13:42 -0800

FWIW, [quic-ah](https://tools.ietf.org/html/draft-kazuho-quic-authenticated-handshake-00) proposes to used the extension field of the ESNI DNS Record to designate the QUIC version the server supports.

Anyways, I think we agree that HTTP3 can be used if there is an arrangement, regardless of what it is; e.g. alt-svc header, alt-svc record, ESNI record...

The question is if we should allow use of HTTP3 without prior arrangement.

I think we should allow that. There’s not always going to be DNS (consider DoH, which will benefit from HTTP3 not having HoLB), and being able to connect using HTTP3 from the first connection helps in certain deployments that we can be fairly certain that there is no firewall in between (e.g. server-to-server traffic).

-- 
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-458906916

---

From: MikkelFJ <[email-masked]>
Date: Wed, 30 Jan 2019 03:27:38 -0800

> I think we should allow that.

yes

-- 
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-458910663

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 30 Jan 2019 04:46:51 -0800

> I see no problems with combining Happy Eyeballs and connection coalescing, but the relationship between them should really be defined somewhere

I definitely think this can be done and that there is benefit in shaking out an approach that can be codified somewhere. There are many spinning plates to manage, add to the mix ORIGIN frame and Additional Certs, even Alt-Svc in the load balancing sense (which has been broken in H2 but is likely to succeed H3). Getting this right seems like an arcane art, or luck, or both :)

-- 
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-458931248

---

From: MikkelFJ <[email-masked]>
Date: Wed, 30 Jan 2019 14:21:11 +0000 (UTC)

> Getting this right seems like an arcane art, or luck, or both :)

Well, if you can convince DDoS attackers to move elsewhere ...

-- 
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-458960759

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jan 2019 22:31:05 -0800

FYI, I just opened https://github.com/httpwg/http-core/issues/194

-- 
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-459232165

---

From: Mike Bishop <[email-masked]>
Date: Wed, 30 Jan 2019 22:31:15 -0800

Discussed in Tokyo; this needs to be resolved by the HTTP WG, and we need to incorporate their resolution into the doc.

-- 
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-459232199