Re: Anycast provider for SMTP?

[Dave Taht <dave.taht () gmail com>]

On Mon, Jun 15, 2015 at 12:34 PM, Joe Abley <jabley () hopcount ca> wrote:
> On 15 Jun 2015, at 15:05, Dave Taht wrote:
>
> > I have been using anycast at a small scale on mesh networks, for dns,
> > primarily. Works.
>
>
> Many of us have been using anycast at Internet scale for DNS for a couple of
> decades. I would go further than "works" and perhaps say "necessary".

Oh, I agree.

My point was that anycast is also potentially of use in smaller
(corporate/mesh) networks, not just in DNS, but smtp as being
discussed here. Web and other forms of proxy, also. Other cases, like
gittorrent?

I'm pretty sure it's a bad idea for ntp, and for non-fully mirrored
file distribution services.

> There were some wise words written in RFC 4786 about use of anycast with
> other protocols (well, I think they are wise, but then I wrote some of
> them):

a good read.

>    When a service is anycast between two or more nodes, the routing
>    system makes the node selection decision on behalf of a client.
>    Since it is usually a requirement that a single client-server
>    interaction is carried out between a client and the same server node
>    for the duration of the transaction, it follows that the routing
>    system's node selection decision ought to be stable for substantially
>    longer than the expected transaction time, if the service is to be
>    provided reliably.
>
>    Some services have very short transaction times, and may even be
>    carried out using a single packet request and a single packet reply
>    (e.g., DNS transactions over UDP transport).  Other services involve
>    far longer-lived transactions (e.g., bulk file downloads and audio-
>    visual media streaming).
>
>    Services may be anycast within very predictable routing systems,
>    which can remain stable for long periods of time (e.g., anycast
>    within a well-managed and topologically-simple IGP, where node
>    selection changes only occur as a response to node failures).  Other
>    deployments have far less predictable characteristics (see
>    Section 4.4.7).
>
>    The stability of the routing system, together with the transaction
>    time of the service, should be carefully compared when deciding
>    whether a service is suitable for distribution using anycast.  In
>    some cases, for new protocols, it may be practical to split large
>    transactions into an initialisation phase that is handled by anycast
>    servers, and a sustained phase that is provided by non-anycast
>    servers, perhaps chosen during the initialisation phase.
>
>    This document deliberately avoids prescribing rules as to which
>    protocols or services are suitable for distribution by anycast; to
>    attempt to do so would be presumptuous.
>
>    Operators should be aware that, especially for long running flows,
>    there are potential failure modes using anycast that are more complex
>    than a simple 'destination unreachable' failure using unicast.
>
>
> Joe



-- 
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast