Subject: [quicwg/base-drafts] GREASE and Version Negotiation Hint (#296)

From: Mike Bishop <[email-masked]>
Date: Mon, 13 Feb 2017 16:44:24 -0800

In #278, @martinthomson says that clients MAY choose a GREASE value for their initial packet to force version negotiation.  I would argue that no self-interested client will do so if the connection is latency-sensitive, since you incur an RTT, unless the spec has this at a higher level than MAY and with specific timing.

However, for HTTP, bringing up a connection to a new Alternative is not latency-sensitive (because you still have your connection to the original host).  In the case where you're bringing up a connection to an alternative instead of to the origin, you've likely talked to the alternative before.

We could consider dropping the Alt-Svc version hint entirely, and saying that clients SHOULD open with a reserved version unless it has previously connected to the server and remembers a version list.

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

---

From: David Benjamin <[email-masked]>
Date: Mon, 13 Feb 2017 16:58:39 -0800

HelloRetryRequest in TLS 1.3 has a similar problem. My thought there was clients could [with low probability|experimentally after a connection is established|subject to resource limits|insert idea heres] do an experimental key_share-less probe to servers we talk to. Once triggered, if any key_share-less probe fails to connect for any reason, we put the server in some "HelloRetryRequest probation" cache. All connections to hosts on probation will be key_share-less until they can satisfactorily connect with HelloRetryRequest [even if there is a socket open?].

But we haven't gotten to playing with this yet. It might not work. Putting hosts on probation or probing too aggressively can degrade performance, while not being aggressive enough will just look like a flaky failure, which probably won't be effective. I'm hoping there's a middle ground that satisfies both constraints.

-- 
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/296#issuecomment-279573813

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Feb 2017 17:04:41 -0800

Unfortunately, the current state of TLS 1.3 implementations is that HRR isn't consistently implemented, so it's not something you can do right away.  And you are right that flaky doesn't get us what we want.

I am hoping that the development process for QUIC will force early implementations to use version negotiation a lot.  That was what happened in HTTP/2 and I see no reason why that wouldn't happen again here.  That was not the case with TLS 1.3 and HRR, TLS 1.3 implementations without HRR weren't (and aren't) punished.

-- 
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/296#issuecomment-279574879

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 13 Feb 2017 17:25:11 -0800

I love the idea of being able to GREASE things in QUIC! 

Dropping the version hint is definitely possible, but it has a downside. There will be old clients out there which speaks versions of QUIC that a server no longer supports. As a result, it is desirable for the server to be able to advertise QUIC, but in such a way that it doesn't lure old client to waste bandwidth trying to speak QUIC with an old version that the server will never support.

I'm also not sure that adding an additional RTT to the first QUIC connection from Alt-Svc is not really latency sensitive. We'd noticed in our QUIC deployment that the more requests go over the TCP connection before switching the QUIC, the less effective QUIC is. (Among other things QUIC and TCP end up competing for bandwidth).

-- 
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/296#issuecomment-279578511

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Feb 2017 18:05:50 -0800

Fair points.  I would say that for a background tab (or an ad, or anything else non-critical), I think that I'd be willing to suck up some latency anyway.  And while it might be suboptimal, the occasional use of greasing won't destroy performance in the same way that it might during a reconnect where QUIC is the only thing that is tried.

-- 
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/296#issuecomment-279585675

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 13 Feb 2017 19:30:57 -0800

Having the client *occasionally* sending a GREASED connection attempt seems quite reasonable. One caveat, of course, is that if we're talking about QUIC in the HTTP context, it's quite likely that the client will have built in TCP fallback. If a server does not properly handle GREASED connections, is there an obvious feedback mechanism? 

-- 
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/296#issuecomment-279598031

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Feb 2017 19:33:48 -0800

No more than what we get when the server advertises a QUIC that is broken in other ways.  That's what Alt-Svc is like.

-- 
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/296#issuecomment-279598394

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 13 Feb 2017 19:53:45 -0800

Hm. That's too bad :( If there's no feedback channel (because of Alt-Svc's graceful fallback) will the incentives line up for GREASE to actually help keep the ecosystem working? As I understand it, with TLS, GREASE errors end up user visible, which makes it obvious to server administrators. Maybe we should make GREASE in QUIC actually fatal? 

-- 
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/296#issuecomment-279601011

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Feb 2017 20:05:21 -0800

The problem here is that any failure in an alternative is buried by design.  You have to expect the alternative to fail.  We could promote certain types of failures so that they tear down all communication to the origin, but that isn't reliable.

If the way that version negotiation failures manifest is a black hole - an unfortunately common failure mode we deal with - how do we tell the difference between that and a server that is off the network?

-- 
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/296#issuecomment-279602401

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 13 Feb 2017 20:08:26 -0800

Yeah, I totally hear you. I'm just saying that (as I understand it) the reason that GREASE works for TLS is that when an endpoint doesn't do the right thing, it's a fatal error which is visible to the user.

If Alt-Svc (by design) hides failures from the user will GREASE work for QUIC?

-- 
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/296#issuecomment-279602764

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Feb 2017 20:15:13 -0800

It depends on how visible QUIC usage is to the server.  If they never see requests over QUIC, or the rate is low by some significant proportion, then there is a *chance* that it could work.   But you are right that it's probably not great.

There is an alternative, but it's disruptive.  Flip the version negotiation on its head.  Have the client include a list of versions in its initial packet and have the server pick the version (and reject if necessary).  No risk there of ever having a wasted RTT.  (There are other latency improvements that can be salvaged from such a design, but they are harder to acquire.)

-- 
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/296#issuecomment-279603530