Elephant in the room - Akamai

Fri Dec 6 19:29:39 UTC 2019

Speaking as a (very) small operator, we've also been seeing less and 
less of our Akamai traffic coming to us over peering over the last 
couple years. I've reached out to Akamai NOC as well as Jared directly 
on a few occasions and while they've been helpful and their changes 
usually have some short-term impact, the balance has always shifted back 
some weeks/months later. I've more or less resigned myself to this being 
how Akamai wants things, and as we so often have to as small fish, just 
dealing with it.

We're currently seeing about 80% of our AS20940 origin traffic coming 
from transit, and I'm certain there's a significant additional amount 
which is difficult to identify coming from on-net caches at our upstream 
providers (though it appears from the thread that may be reducing as 
well). Only about 20% is coming from peering where we have significantly 
more capacity and lower costs. Whatever the algorithm is doing, from my 
perspective it doesn't make a lot of sense and is pretty frustrating, 
and I'm somewhat concerned about busting commits and possibly running 
into congestion for the next big event that does hit us, which would not 
be a problem if it were delivered over peering.

Luckily we're business focussed, so we're not getting hit by these 
gaming events.

Keenan Tims
Stargate Connections Inc (AS19171)

On 2019-12-06 8:13 a.m., Jared Mauch wrote:
>
>> On Dec 6, 2019, at 9:59 AM, Chris Adams <cma at cmadams.net> wrote:
>>
>> Once upon a time, Fawcett, Nick <nfawcett at corp.mtco.com> said:
>>> We had three onsite Akamai caches a few months ago.  They called us up and said they are removing that service and sent us boxes to pack up the hardware and ship back.  We’ve had quite the increase in DIA traffic as a result of it.
>> Same here.  We'd had Akamai servers for many years, replaced as needed
>> (including one failed servre replaced right before they turned them
>> off).  Now about 50% of our Akamai traffic comes across transit links,
>> not peering.  This seems like it would be rather inefficient for them
>> too…
> There’s an element of scale when it comes to certain content that makes it not viable if the majority of traffic is VOD with variable bitrates it requires a lot more capital.
>
> Things like downloads of software updates (eg: patch Tuesday) lend themselves to different optimizations.  The hardware has a cost as well as the bandwidth as well.
>
> I’ll say that most places that have a few servers may only see a minor improvement in their in:out.  If you’re not peering with us or are and see significant traffic via transit, please do reach out.
>
> I’m happy to discuss in private or at any NANOG/IETF meeting people are at.  We generally have someone at most of the other NOG meetings as well, including RIPE, APRICOT and even GPF etc.
>
> I am personally always looking for better ways to serve the medium (or small) size providers better.
>
> - Jared
>