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@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