Subject: Re: [quicwg/base-drafts] IP Anycast with server IP+Port renegotiation (#560)

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Aug 2017 05:03:23 +0000 (UTC)

I'd like to hear from server operators whether they see the need for this sort of capability.  Otherwise I think that we should park this.

It's certainly possible to define a new frame type (call it MIGRATE) that acts much like the [HTTP Alt-Svc frame](https://tools.ietf.org/html/rfc7838).  An endpoint that receives it might move to the new transport endpoint as soon as feasibly possible.  For this, you would want to pair MIGRATE with NEW_CONNECTION_ID so that linkability could be broken.

We'd also have to be careful not to accidentally define multipath, because the natural reaction to this is to retain the old path until the new path has a sufficiently wide congestion window.

In any case, the frame that tests the new path for liveness is necessary before we address this.  See #161 for more on that.

-- 
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/560#issuecomment-322100982

---

From: Christian Huitema <[email-masked]>
Date: Mon, 14 Aug 2017 05:42:05 +0000 (UTC)

The anycast support is simpler than general server mobility.  Server only need to send the non-unicast address once. They could send the preferred IP address & port as part of the transport parameter TLS extension, probably together with a new connection ID.

I would also like to see a possibility to MIGRATE later in the connection, but that's a different issue.

I agree that this looks a bit like #161, but on the other hand, server initiated DOS is a much less acute problem that client initiated DOS. Currently, a server can easily send the client a script that will trick the client into bombing random locations -- I think the great cannon worked just like that. The general defense is to identify the server...

-- 
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/560#issuecomment-322104581

---

From: ThomasSwindells <[email-masked]>
Date: Mon, 14 Aug 2017 01:57:19 -0700

As a CDN operator this proposal looks valuable to me, in a long lived connection context (e.g. HTTP etc) quickly moving clients off the anycast address onto a server specific address provides a reliable means for machines to stop advertising the anycast address when they become busy(loaded) but still continue to serve existing connections.

As Christian has pointed out the option to also use MIGRATE later in the connection is also an interesting concept with value, but that is definitely a different issue.

-- 
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/560#issuecomment-322135139

---

From: mirjak <[email-masked]>
Date: Mon, 14 Aug 2017 10:14:04 +0000 (UTC)

One side comment, I think any make-before-break solution is basically multipath, and as such we should make sure if we design such a mechanism that it can also be used for multi path correctly. So yes, we shouldn't design multipath by accident but if multipath is what we need for another feature that we would like to support, we should design it as providing 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/560#issuecomment-322153305

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 21 Aug 2017 01:12:23 -0700

Echoing Christian's and Thomas' comments. 

The early-handoff of clients to a specific address could be a useful capability for deployments. In addtion to anycast, this could also be beneficial for load balanced deployments that use ECMP.

The compromise with the TLS extension is that relocation chaining would not be supported (e.g. a service on one anycast IP, directs to another anycast IP, that directs to a non-anycast IP). A MIGRATE frame could deal with this, along with a multitude of other more complex deployments.

-- 
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/560#issuecomment-323676438

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 21 Aug 2017 18:42:34 +0000 (UTC)

Would not one be able to use Server-generated Connection ID to encode the server/pop containing state for this connection?  In case of BGP reconvergence, the server/load balancer would examine the Connection ID and tunnel the packet to the correct server/pop.

If a true "Alt-Svc-for-QUIC" is needed, I am all for migrating truly useful features to lower layers (like transport).  But does this feature HAVE to belong in transport?  Since we are already considering not using a 5-tuple to identify a connection (see #714), a MIGRATE signal can be an application-level signal, as long as the QUIC library API allows the application to change its endpoint's IP/port.

-- 
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/560#issuecomment-323820454

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 Aug 2017 22:10:55 +0000 (UTC)

I don't see this as being ALTSVC -- ALTSVC by definition implies the other endpoint is an acceptable *alternative* the client should consider for the future, not a "move now" directive.  However, I do see this as being a special case of server-side migration.  We can borrow the logic from Teredo of sending appropriate bubble packets to open the NAT, but we should keep things symmetrical with an eye toward peer-to-peer uses of QUIC.

Perhaps the MIGRATE frame simply says, "I expect to shortly begin using this IP/port/Connection ID; please send a PING frame to that destination"?  The recipient then begins the process in #732 as if it had just received a packet from that IP/port.

We'd need to think about attacks where the sender knows there's an existing QUIC connection at that IP/port with that Connection ID (the attempt to validate then looks like an address change from the target connection's peer), but I'd hope that it's sufficiently difficult to force your connection to use the same key as the target, so decryption would just drop the packet.

-- 
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/560#issuecomment-324166090