Elephant in the room - Akamai

Sun Dec 8 16:41:55 UTC 2019

Let's take a minute and thank Jared for taking the time and responding.

thank you, Jared.

On Sun, Dec 8, 2019 at 10:58 AM Jared Mauch <jared at puck.nether.net> wrote:

> Not all content is suitable in all locations based on the physical
> security or market situation. We have some content that can not be served,
> an example is locations where there are licensing requirements (eg: ICP for
> China).
>
> You will see a different mix from our 20940 vs 16625 as well. Those have
> different requirements on the security side. If you treat your PKI data
> seriously you will appreciate what is done here.
>
> In Marquette Michigan there will be different opportunities compared with
> Amsterdam or Ashburn as well.
>
> Our customers and traffic mix makes it challenging to serve from a
> platform where you do capital planning for several year depreciation cycle.
> We have thousands of unique sites and that scale is quite different from
> serving on a few distinct IXPs and transit providers.
>
> So yes you will see a difference and there are things we can do to improve
> it when there is a variance in the behavior.
>
> - Jared
>
> > On Dec 8, 2019, at 10:33 AM, Brandon Martin <lists.nanog at monmotha.net>
> wrote:
> >
> > On 12/7/19 7:19 PM, Jared Mauch wrote:
> >> Please see my email on Friday where I outlined a few of the dynamics at
> play.  Akamai isn’t just one thing, it’s an entire basket of products that
> all have their own resulting behaviors.  This is why even though you may
> peer with us directly you may not see 100% of the traffic from that
> interconnection.  (Take SSL for example, it’s often not served via the
> clusters in an ISP due to the security requirements we place on those
> racks, and this is something we treat very seriously!)
> >
> > Does this mean that, if you peer with Akamai at some location, only
> content locally available at that location will come over that peering
> session with the rest coming via other means?  Does Akamai not have private
> connectivity to their public peering points?
> > --
> > Brandon Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191208/980c5381/attachment.html>