Akamai Edgekey issues ?

Tue Sep 3 14:37:48 UTC 2013

On Sep 03, 2013, at 09:58 , Jay Ashworth <jra at baylink.com> wrote:
>> From: "Matthew Petach" <mpetach at netflight.com>
>> On Mon, Sep 2, 2013 at 7:33 PM, Jorge Amodio <jmamodio at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130903/0dc3164c/attachment.sig>