On 3/21/13, Constantine A. Murenin <mureninc@gmail.com> wrote:
Does it sound too complicated and pointy? Yes, it's not exactly trivial, and not as good as BGP, but better than having 300ms latency from a simple round-robin.
It sounds like you are asking about Geolocation, when what you really want is latency-based selection. Latency is more complicated, and influenced by factors other than purely Geographic location. Furthermore, distance doesn't work all that well as a measure of latency: it only defines the latency, in the best case scenario for a link between the geo locations. Why not just have the browser send a SYN packet to every IP in the A/AAAA RRSET? Whichever webserver's response to the connection handshake is received first wins (lowest RTT latency); the other two or three connections are just dropped, so there is some minor waste, in exchange for picking the lowest RTT destination. Now another alternative would be for the local network operator to offer some sort of "latency lookup service"; Based on implementing packet inspection, and gathering statistical information RTT and average throughput and retransmit rates experienced during network users' TCP handshakes to remote prefixes, aggregated at an AS level. So the browser could query the latency lookup service for the hostname, and receive a DNS reply annotated with an estimated historical average latency, drop rate, throughput for the IP prefix inquired about. Or in fact... have the lookup service re-order or filter the query result, so the responses with higher than a certain cutoff latency are placed last in the response, or filtered/deleted from the response, when there are at least 3 better choices.
C. -- -JH