Why are there no GeoDNS solutions anywhere in sight?

[mysidia at gmail.com (Jimmy Hess)]

On 3/21/13, Constantine A. Murenin <mureninc at 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