Subject: [quicwg/base-drafts] Document how a server cluster might be upgraded (#504)

From: Martin Thomson <[email-masked]>
Date: Thu, 04 May 2017 16:45:07 -0700

... and rolled back.

Version negotiation has a bunch of properties that make upgrading a cluster of servers a non-trivial task.  If you accept that changes to nodes will happen piecemeal, then you can end up in a situation where some part of the cluster supports a higher version than the rest.  This suggests a two-stage roll-out for new versions.  We should write that down.

@mirjak, I don't know if you want to take this on in the manageability document.  That might be a good place for this sort of discussion.

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

---

From: janaiyengar <[email-masked]>
Date: Thu, 04 May 2017 18:42:14 -0700

I don't think we need to be documenting this. The implications to QUIC are straightforward -- a client receives a version negotiation packet -- but that's already expected. It's up to server deployments to figure out if this is cost they care to fix via more process for upgrades. Besides, different server deployments already have their own processes.

-- 
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/504#issuecomment-299352291

---

From: mirjak <[email-masked]>
Date: Mon, 08 May 2017 02:06:58 -0700

I guess it could be interesting to mention somewhere that you can use the server selected connection ID to redirect to a server that you know supports the requested version. But not sure where it would be documented best. The manageability doc was support to be directed at network operator and this is a server operator thing, so maybe the applicability statement fits better...?

-- 
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/504#issuecomment-299813570

---

From: Martin Thomson <[email-masked]>
Date: Mon, 08 May 2017 03:05:00 -0700

There's more to it than that.  The version doing the redirect has to advertise the versions that the target node supports, even if that set differs from its own.  Including any greasing.  Otherwise the handshake will fail.  That implies some amount of coordination across a server cluster.

-- 
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/504#issuecomment-299826332

---

From: janaiyengar <[email-masked]>
Date: Wed, 10 May 2017 22:53:04 -0700

This may be worth discussing at the interim.

-- 
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/504#issuecomment-300689647