Anycast provider for SMTP?
Dave Taht
dave.taht at gmail.com
Mon Jun 15 19:54:44 UTC 2015
On Mon, Jun 15, 2015 at 12:34 PM, Joe Abley <jabley at 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
More information about the NANOG
mailing list