GeoIP information

Fri Sep 25 17:39:22 UTC 2015

You're example is one specific case.  I'm not advocating that it works in
every case, or that geo-location should be used in routing decisions
exclusively.  I have dealt with cases in which a CDN responded to a client
request with a resource on another continent, thus having to cross an ocean
and adding considerable latency, when there was a POP on that continent.
If the CDN could have LOC information that is more accurate/updated, it
could allow them to make a better decision and direct a client to a
resource that is physically closer.  It's another piece of information.
Clearly Maxmind or whatever other current means there are to determine
physical location are not ideal.

Clay

On Fri, Sep 25, 2015 at 12:44 PM, <Valdis.Kletnieks at vt.edu> wrote:

> On Fri, 25 Sep 2015 10:43:13 -0400, Clay Curtis said:
> > I don't believe anyone is actually using the LOC RR, but maybe I'm wrong.
> > This seems like the best way to store this type of data.  I could see
> CDNs
> > being able to leverage this along with edns-client-subnet to decrease
> page
> > load times significantly.
>
> How is knowing the physical location going to decrease page load times?
>
> Hint:  I live all of 3 miles from my office.  But home is deep in Comcast
> cable territory, while office is hanging off connections to Ashburn and
> Atlanta. So from home to office, packets have to go 400 miles north or
> south,
> then back.  If Akamai decided to serve me a page at home out of the Akamai
> servers at work because it's only 3 miles away, it just added 25ms to each
> RTT it has to take.
>
> Which is why Akamai (and any other *sane* CDN) make their decisions based
> on network topology, not physical location....
>