Re: Akamai Edgekey issues ?

["Patrick W. Gilmore" <patrick () ianai net>]

On Sep 03, 2013, at 09:58 , Jay Ashworth <jra () baylink com> wrote:
> > From: "Matthew Petach" <mpetach () netflight com>
> > On Mon, Sep 2, 2013 at 7:33 PM, Jorge Amodio <jmamodio () gmail com> wrote:
> >
> > > Here is another bit of data... www.apple.com not reachable from a
> > > machine
> > > using Google's NS, reachable from an iPad using TWC NS
> > >
> > > IP addresses returned by each are different ... could be load
> > > balancing, or
> > > creative (broken) traffic engineering
>
> > Far more likely to be simply due to Akamai
> > localizing the IP addresses to be as "close"
> > to the resolving nameserver as possible;
> > so, when using Google DNS, you end up
> > at an Akamai node "close" to the Google
> > DNS server; when using the TWC nameservers,
> > you end up pointing to an Akamai node closer
> > to those TWC nameservers.
> >
> > Not a case of "broken" traffic engineering at all.
>
> Sure it is. 
>
> It's assuming that the geographic location of a customer resolver server
> has anything whatever to do with the geographic location of the end node,
> which it's not in fact a valid proxy for.

It isn't? How wrong is this assumption? Be specific. How far off is it, for how many users?

Perhaps look at the other side. Assumptions must be made. What assumptions would be better in the real world? What 
percentage of users are "closer" to anycast nodes? What are the real-world performance differences using this method 
vs. other methods?

Saying "not in fact a valid proxy" without hard data is not useful. What data do you have to prove your thesis?

Akamai seems to perform well for the vast majority of users. Or so I believe, but I fully admit I am biased. :)

That said, always happy to be educated. If you have data, let us know.

-- 
TTFN,
patrick

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail