4 ms·

Did you miss the part where they tested and confirmed that the IPs in question have better latency to the "right" datacenters, and are still being sent to the w

Did you miss the part where they tested and confirmed that the IPs in question have better latency to the "right" datacenters, and are still being sent to the wrong ones? GeoIP is not the problem, route53 is.

aristus 13y ago
I mean that the basic idea of GeoIP routing, ie that physical location is a good enough proximity for "internet distance" doesn't work, especially at the edges. The fact that the OP isn't hosted in EC2 but in "locations [that] map well to AWS regions" throws the whole thing off. It doesn't matter if their servers are across the street -- Amazon likely doesn't have good latency and routing information for datacenters it does not own. R53 exists to make DNS-based global server load balancing optimal for EC2 servers. They have little incentive (and limited ability) to make it right for random datacenters. And OP's intuition is right -- balancing at the DNS level means balancing at the DNS resolver level (leaving aside edns stuff), which adds another layer of coarseness out of Amazon's control. Either way, data wins arguments and I'm prepared to be wrong. To test this more thoroughly, OP could spin up an instance in each EC2 region their real systems "map well" to, proxy to the real systems, and see if the routing gets better.
- latch 13y ago
  OP here. Little harsh.. laughably wrong? I did point out that we've seen this same behavior with EC2 instances (1) before. So there's a tiny bit of evidence to suggest it might not be such a joke. Maybe this is what's lame, but I just don't think you are right about AWS vs non-AWS locations. Amazon's stance on this does make it clear that you aren't necessarily going to get the most optimal route (2) , true. But latency within Singapore tends to be measured in single digit ms (it's 710 KM2). What you are suggesting (if I understand correctly) is that a Singaporean's latency to US-East-1 can be faster than his or her latency to US-Southeast-1. I took some of those IPs, pinged them from EC2 instances in those regions and it's the same result. I agree GeoIP is a best-guess effort, especially with public dns. But if nothing else, the analysis merely confirms that. (1) https://forums.aws.amazon.com/message.jspa?messageID=384090 https://forums.aws.amazon.com/message.jspa?messageID=384090 (2) https://forums.aws.amazon.com/message.jspa?messageID=330523#330523 https://forums.aws.amazon.com/message.jspa?messageID=330523#...
- papsosouid 13y ago
  No, you are simply wrong. The problem here has absolutely nothing to do with geoIP. The geoIP lookups are correct. The issue is entirely that people use DNS servers that are no where near them. Don't insist other people are wrong while you are making up nonsense that was already clearly demonstrated wrong in the original article.

aristus 13y ago

I mean that the basic idea of GeoIP routing, ie that physical location is a good enough proximity for "internet distance" doesn't work, especially at the edges. The fact that the OP isn't hosted in EC2 but in "locations [that] map well to AWS regions" throws the whole thing off. It doesn't matter if their servers are across the street -- Amazon likely doesn't have good latency and routing information for datacenters it does not own. R53 exists to make DNS-based global server load balancing optimal for EC2 servers. They have little incentive (and limited ability) to make it right for random datacenters. And OP's intuition is right -- balancing at the DNS level means balancing at the DNS resolver level (leaving aside edns stuff), which adds another layer of coarseness out of Amazon's control. Either way, data wins arguments and I'm prepared to be wrong. To test this more thoroughly, OP could spin up an instance in each EC2 region their real systems "map well" to, proxy to the real systems, and see if the routing gets better.

latch 13y ago
OP here. Little harsh.. laughably wrong? I did point out that we've seen this same behavior with EC2 instances (1) before. So there's a tiny bit of evidence to suggest it might not be such a joke. Maybe this is what's lame, but I just don't think you are right about AWS vs non-AWS locations. Amazon's stance on this does make it clear that you aren't necessarily going to get the most optimal route (2) , true. But latency within Singapore tends to be measured in single digit ms (it's 710 KM2). What you are suggesting (if I understand correctly) is that a Singaporean's latency to US-East-1 can be faster than his or her latency to US-Southeast-1. I took some of those IPs, pinged them from EC2 instances in those regions and it's the same result. I agree GeoIP is a best-guess effort, especially with public dns. But if nothing else, the analysis merely confirms that. (1) https://forums.aws.amazon.com/message.jspa?messageID=384090 https://forums.aws.amazon.com/message.jspa?messageID=384090 (2) https://forums.aws.amazon.com/message.jspa?messageID=330523#330523 https://forums.aws.amazon.com/message.jspa?messageID=330523#...
papsosouid 13y ago
No, you are simply wrong. The problem here has absolutely nothing to do with geoIP. The geoIP lookups are correct. The issue is entirely that people use DNS servers that are no where near them. Don't insist other people are wrong while you are making up nonsense that was already clearly demonstrated wrong in the original article.