Subject: [Spud] SPUD and anycast... ?!

From: Toerless Eckert <[email-masked]>
Date: Fri, 14 Aug 2015 00:04:11 -0700

Was there ever an extension for TCP or SCTP to "explicitly" deal with
anycast, eg: SYN to reponder anycast, SYN-ACK back from responder
unicast, but with data field indicating anycast address and nonce from
SYN, then ACK back to responder unicast ?

I can't remember / find anything like this right now. WOuld be
lovely for SPUD to consier including something like this. Heck,
could even do this with multicast and let initiator send ACK
back to fastest responder ;-)

Cheers
    Toerless

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 14 Aug 2015 09:39:57 +0200

> On 14 Aug 2015, at 09:04, Toerless Eckert <[email-masked]> wrote:
> 
You can do that with SCTP and dynamic address re-conifguration. Randy
Stewart and myself discussed this ages ago but never wrote an ID, since
we didn't see a consumer of the idea.

Best regards
Michael
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 14 Aug 2015 04:59:39 -0700

http://www.cachefly.com/2014/07/11/measuring-throughput-performance-dns-vs-tcp-anycast-routing/

Even beyond this easily googled example, i think that anycast TCP is
used quite a bit and on web application you can often just have short
lived TCP connection running completely on the anycast address and just
redirect to a unicast URL when you know it's going to be long-lived (streaming).
So i think the reason why this  may not have come up is because for a good amount
of applications, just ignoring the anycast problem leads to good enough
solutions, and the solutions where this would not work may not had
enough of a business case / working strategy to get this type of extension
forced into TCP.

Cheers
   toerless

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 14 Aug 2015 15:19:00 +0200

> On 14 Aug 2015, at 13:59, Toerless Eckert <[email-masked]> wrote:
> 
If you want to use anycast with TCP, how do you make sure that all TCP
packets with the same anycast destination address end up at the same host?
For SCTP you would only use an anycast address as the destination address of
the first packet and then the server uses a unicast address. Since SCTP
supports multiple IP addresses and dynamic address reconfiguration, that
is possible. Similar things can be done with MPTCP, but not with TCP.

Best regards
Michael

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 14 Aug 2015 06:23:52 -0700

> packets with the same anycast destination address end up at the same host?

My paragraph meant to imply that the whole TCP connection does use anycast
in this case, and the different instances of the anycast group are deployed
so that ECMP can't happen, so the TCP connections will only fail in case
of re-routing that changes metrics to have the anycast address flip over
and that doesn't seem to a big enough problem in the deployment cases -
because the servers are far enough apart from each other for example.

> is possible. Similar things can be done with MPTCP, but not with TCP.

I thought to remembre from long time ago that the only architecturally
sane anycast assumption is that a single packet will only reach a single
anycast group member. As soon as you send two packets they may end uup
in different ones. Of course, likelyhood for this is quite small. SO all
i was saying is that it wold be lovely for SPUD to be able to support
architecturally sane use of anycast. Seems simple enough to permit it.

Cheers
    Toerless

---

From: Michael Thornburgh <[email-masked]>
Date: Fri, 14 Aug 2015 23:34:27 +0000

RTMFP (RFC 7016) supports opening to an anycast or multicast address "out of the box".  these cases aren't explicitly called out in the spec, but the same mechanism that supports parallel open, redirectors, forwarders, and load distribution/fault tolerance also supports anycast/multicast.  see Section 3.5.1 (and subsections) of RFC 7016.

opening to an anycast address could work in these ways:

  1. anycast responder uses the anycast address for the session, as long as the anycast routing is consistent for the lifetime of the session (otherwise the session will time out and die), same as with TCP or anything else

  2. anycast responder uses its unicast address to respond with its RHello, session is established to the unicast address

  3. anycast responder uses its anycast address to respond with a Redirect listing the responder's unicast address, initiator then tries unicast address and establishes the session

note that if the client has an address/port restricted NAT or firewall, 2 won't work, but 3 would.

for opening to a multicast address, the responders would all respond with an RHello. whichever one was received first would win and be selected by the initiator for the session, and the other responses would be ignored (the same situation as for the load distribution case in Section 3.5.1.7).

-mike

> -----Original Message-----
> From: Spud [mailto:[email-masked]] On Behalf Of Toerless Eckert
> Sent: Friday, August 14, 2015 6:24 AM
> To: Michael Tuexen
> Cc: [email-masked]
> Subject: Re: [Spud] SPUD and anycast... ?!
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 14 Aug 2015 21:23:34 -0700

Nice.

Does 3. in RTMFP imply one more RTT to start the session ?
to just seed a (good) NAT/FW, it should be sufficient for responder to
send the ACK to the responder instead of restarting with SYN ?! (to avoid one more RTT).

Don't find the word multicast in the text though...

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Michael Thornburgh <[email-masked]>
Date: Sun, 16 Aug 2015 00:26:39 +0000

yes, 3 implies one more RTT.  you wouldn't want to have a combo redirect/RHello coming from the anycast address and just believe the unicast address in the redirect, because the initiator might not have bidirectional connectivity to the unicast address, or the initiator might use a different source address to reach the unicast address (which might produce a different cookie, which would then take an additional RTT anyway, see Section 3.5.1.2).

you could potentially save an RTT by combining 3 and 2 (sending a Redirect from the anycast address AND sending an RHello from the unicast address).  if the RHello gets through then you're good, and if it doesn't then you spend an extra RTT after receiving the Redirect.  this would be very similar to the situation in Section 3.5.1.6.

> Don't find the word multicast in the text though...

as i said, anycast and multicast use cases aren't called out explicitly in the spec.  but they work with no special handling because there's already support for multiple responders responding to the same IHello.  the initiator matches the open responses based on an opaque tag rather than on IP address & port number, latches on the first acceptable response no matter where it comes from, and uses the address/port from which that response came as the far socket address for the session.

note that once the session is up, the address of either end can change, and, depending on the NAT/firewall situation between the endpoints, the session can survive the address change.  see Section 3.5.3 and Section 3.5.4.2.

-mike
________________________________________
From: Toerless Eckert [[email-masked]]
Sent: Friday, August 14, 2015 9:23 PM
To: Michael Thornburgh
Cc: [email-masked]
Subject: Re: [Spud] SPUD and anycast... ?!

Nice.

Cheers
    Toerless