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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf