On Wed, 20 Apr 2005, Patrick W. Gilmore wrote:
On Apr 20, 2005, at 3:29 PM, Dean Anderson wrote:
Or don't. No one here cares if you do. Reality trumps lab tests.
"Reality" for the last ten years has been that no one did either PPLB or TCP DNS. That reality is changing. It'll probably start to change faster, sooner. Then, users will start to notice the problems.
People have been using TCP applications on anycast for at least a decade, as I mentioned before. Since DNS responses tend to be very short lived TCP session, it seems to me that if it works for other applications (e.g. HTTP), it should work for DNS.
I don't know of any HTTP servers that do anycast. But their failure to take account of PPLB doesn't change anything. IF they are anycasting under false assumptions, they'll have problems, too. Perhaps you should read RFC 1546, which prescribes how to do TCP anycast. Then note that TCP anycast requires OS support which is not implemented in any unix-like system (or any system) that I know of. So, instead of following this prescription, the (DNS) anycast promoters have relied on an assumption of unique and slowly changing paths to eliminate the possibility that "two successive TCP segments sent to the anycast peer might be delivered to completely different hosts." But PPLB makes that "paths change slowly" assumption false, because it can use different paths on sequential packets.
From RFC 1546 (page 5)
How UDP and TCP Use Anycasting It is important to remember that anycasting is a stateless service. An internetwork has no obligation to deliver two successive packets sent to the same anycast address to the same host. Because UDP is stateless and anycasting is a stateless service, UDP can treat anycast addresses like regular IP addresses. A UDP datagram sent to an anycast address is just like a unicast UDP datagram from the perspective of UDP and its application. A UDP datagram from an anycast address is like a datagram from a unicast address. Furthermore, a datagram from an anycast address to an anycast address can be treated by UDP as just like a unicast datagram (although the application semantics of such a datagram are a bit unclear). TCP's use of anycasting is less straightforward because TCP is stateful. It is hard to envision how one would maintain TCP state with an anycast peer when two successive TCP segments sent to the anycast peer might be delivered to completely different hosts. The solution to this problem is to only permit anycast addresses as the remote address of a TCP SYN segment (without the ACK bit set). A TCP can then initiate a connection to an anycast address. When the SYN-ACK is sent back by the host that received the anycast segment, the initiating TCP should replace the anycast address of its peer, with the address of the host returning the SYN-ACK. (The initiating TCP can recognize the connection for which the SYN-ACK is destined by treating the anycast address as a wildcard address, which matches any incoming SYN-ACK segment with the correct destination port and address and source port, provided the SYN-ACK's full address, including source address, does not match another connection and the sequence numbers in the SYN-ACK are correct.) This approach ensures that a TCP, after receiving the SYN-ACK is always communicating with only one host. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000