On Sun, 16 May 2004, Joe Abley wrote:
On 16 May 2004, at 18:22, Dean Anderson wrote:
... and that further, the root servers
operators have widely adopted a dubious anycast replication model that
won't work well with TCP and load-balancing BGP configurations that are
gaining the interest of ISPs. Such load balancing configurations will
send
packets over different paths to the same IP address. This is
significant
because an Anycast server is two (or more) physical servers with the
same
IP address, but with different paths to each server to distribute load.
This is not the case with F (I can't speak for other operators
deploying Internet-scope anycast services). The different paths are
made available in order to provide redundancy and diversity, and
absolutely not to share load.
I don't have the list of roots using anycast handy (I think might have
been published on Namedroppers though), and I don't remember if F was
amoung them.
If you have an example of someone enabling multi-path BGP hacks in
order to allow selection of more than one path, and specifically one
who has ever selected two or more paths to different nodes of F (that
is, paths to 192.5.5.0/24) I would be very interested to hear about it.
It is conceptually very simple: Setup 2 anycast servers (S1 and S2) on
several paths (AS-A and AS-Y, different AS numbers) Have an ISP connect
to both of those paths, and then have that ISP do fine grained load
balancing to prefixes available over those paths. Packets will go to each
anycast server. This will not cause a problem with UDP, since the entire
connection transaction is in one packet. But TCP will have a minumim of 3
packets. 2 packets will go to server S1, and one packet will go to server
S2. Neither S1 nor S2 will have a complete TCP connection, and so both
will fail.
Feedback and measurement data we have seen has not yet revealed an
occurrence of this, and conversations so far with operators does not
suggest there is much risk that we will. Your data will be interesting
to hear, however, if you can pass it on.
This is because most (vast bulk?) traffic to the root's is UDP. It may
also be the case that no ISPs are doing fine-grained load balancing to the
specific paths which happen to go to the root servers using anycast.
However, this configuration is just a matter of chance. One can't make
operational plans based on essentially false assumptions that a) no one
does TCP DNS queries, and b) no one does fine grained load balancing, or
c) no one does fined grained load balancing on the paths that lead to
anycast root servers.
Anycast only works on UDP, and only one single packet transactions with no
other state. If your application cannot meet those requirements, it is
unsuitable for anycast. UDP DNS meets those requirements. TCP DNS does
not.
Anycast will not cause problems with single packet UDP DNS queries,
but will have problems with load balanced, TCP connections, especially
where BGP load balancing configurations would be likely to send
packets over different paths (and thus to different anycast servers)
within a very short period of time, perhaps even sequential packets
could sent over different paths.
There is a risk that during a routing transition, when one path to
192.5.5.0/24 is promoted over another due to a link failure or some
other policy or topology change, a TCP transaction to an anycast node
will fail. This is documented in both ISC technical notes written to
describe what we are doing with F.
This is a course-grained route switch. There is no way to avoid such
connection failure, because one server containing the TCP state, failed.
As has been pointed out, such route changes are infrequent. Route churn
is a minor problem, and unrelated to fine-grained load balancing, in which
packets are simultaneously sent over two different paths.
--Dean
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf