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

[Michael Thornburgh <[e-mail]>]

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 [[e-mail]]
Sent: Friday, August 14, 2015 9:23 PM
To: Michael Thornburgh
Cc: [e-mail]
Subject: Re: [Spud] SPUD and anycast... ?!

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

On Fri, Aug 14, 2015 at 11:34:27PM +0000, Michael Thornburgh wrote:
> 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:[e-mail]] On Behalf Of Toerless Eckert
> > Sent: Friday, August 14, 2015 6:24 AM
> > To: Michael Tuexen
> > Cc: [e-mail]
> > Subject: Re: [Spud] SPUD and anycast... ?!
> >
> > On Fri, Aug 14, 2015 at 03:19:00PM +0200, Michael Tuexen wrote:
> > > > On 14 Aug 2015, at 13:59, Toerless Eckert <[e-mail]> wrote:
> > > >
> > > > 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
> >
> > > 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?
> >
> > 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.
> >
> > > 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.
> >
> > 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
> >
> > > Best regards
> > > Michael
> > > > 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
> > > >
> > > > On Fri, Aug 14, 2015 at 09:39:57AM +0200, Michael Tuexen wrote:
> > > >>> On 14 Aug 2015, at 09:04, Toerless Eckert <[e-mail]> wrote:
> > > >>>
> > > >>> 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 ?
> > > >> 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
> > > >>>
> > > >>> 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
> > > >>>
> > > >>> _______________________________________________
> > > >>> Spud mailing list
> > > >>> [e-mail]
> > > >>> https://www.ietf.org/mailman/listinfo/spud
> >
> > _______________________________________________
> > Spud mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spud

--
---
Toerless Eckert, [e-mail]