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

[Toerless Eckert <[e-mail]>]

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