wow, lots of akamai

Thu Apr 1 21:04:34 UTC 2021

No disrespect taken, or intended back in your direction, but again, I
disagree.

If thousands of users are downloading 50G files at the same time, it really
doesn't matter if they are pulling from a CDN or the origin directly. The
volume of traffic still has to be handled. Yes, it's a burden on the ISP,
but it's a burden created by the usage created by their subscribers.

On Thu, Apr 1, 2021 at 4:57 PM Matt Erculiani <merculiani at gmail.com> wrote:

> Tom,
>
> All due respect, but there is a massive difference between one user
> downloading 50G and thousands of users each downloading 50G when they all
> go to play their videogame of choice at around the same time.
>
> -Matt
>
>
>
> On Thu, Apr 1, 2021 at 2:46 PM Tom Beecher <beecher at beecher.cc> wrote:
>
>> A user sends a few megabytes of request and receives 50 gigs of reply.
>>> They aren't DDoSing the network, but they're amplifying a single 50 gig
>>> copy they receive from the mothership and turning it into likely tens of
>>> terabytes of traffic.
>>> Yes, that's a CDN's job, but that volume of legitimate traffic and the
>>> very tiny window with which it is transmitted is likely to be a burden for
>>> even the largest residential ISPs.
>>>
>>
>> I'm sitting at home, and I could send a 50k request for a 50G file right
>> now from a source not fronted by a CDN. What do? My ISP is still has to
>> deliver it to me. The fact that the 50G file does or does not come from a
>> CDN is irrelevant. The CDN just happens to be a point source that a lot of
>> users happen to connect to.
>>
>> CDNs want to have the best performance to users because that's what
>> brings them business. A poorly performing CDN will lose customers to a
>> better performing one. The trend for years has been instead of ISPs
>> investing in infrastructure to effectively handle the traffic that their
>> users request, they turf that to CDNs. In many cases, a CDN will put a
>> cache box in or extend a circuit at a loss to them, because they know if
>> the performance metrics get bad, business will be taken elsewhere, even if
>> the CAUSE of the poor performance is actually at the edge of, or inside ,
>> the ISPs network.
>>
>> ISPs in the US can get away with this because their users are captive and
>> rarely have an alternative choice of provider.
>>
>>
>> On Thu, Apr 1, 2021 at 4:33 PM Matt Erculiani <merculiani at gmail.com>
>> wrote:
>>
>>> Patrick,
>>>
>>> > First, to be blunt, if you really think Akamai nodes are “sitting idle
>>> for weeks” before CoD comes out with a new game,
>>> > you are clearly confused.
>>>
>>> "Idle" in the sense that when you look at a graph of traffic before and
>>> after a large push such as this makes the rest of the week's traffic look
>>> like a horizontal line at the bottom, admittedly poor word choice, yes, but
>>> far from "confused" as to what CDNs do under relatively normal
>>> circumstances. Otherwise very valid points you've raised.
>>>
>>> Tom,
>>>
>>> > Akamai, and other CDNs, do not **generate** traffic ; they serve the
>>> requests generated by users.
>>>
>>> A user sends a few megabytes of request and receives 50 gigs of reply.
>>> They aren't DDoSing the network, but they're amplifying a single 50 gig
>>> copy they receive from the mothership and turning it into likely tens of
>>> terabytes of traffic.
>>> Yes, that's a CDN's job, but that volume of legitimate traffic and the
>>> very tiny window with which it is transmitted is likely to be a burden for
>>> even the largest residential ISPs.
>>>
>>> -Matt
>>>
>>> On Thu, Apr 1, 2021 at 2:09 PM Patrick W. Gilmore <patrick at ianai.net>
>>> wrote:
>>>
>>>> Matt:
>>>>
>>>> I am going to disagree with your characterization of how Akamai - and
>>>> many other CDNs - manage things. First, to be blunt, if you really think
>>>> Akamai nodes are “sitting idle for weeks” before CoD comes out with a new
>>>> game, you are clearly confused.
>>>>
>>>> More importantly, I know for a fact Akamai has spent ungodly amounts of
>>>> money & resources putting content precisely where the ISPs ask them to put
>>>> it, deliver it over the pipes the ISPs ask them to deliver it, at precisely
>>>> the capacity the ISPs tell them.
>>>>
>>>> On the other hand, I agree with your characterization of residential
>>>> broadband. It is ridiculous to expect a neighborhood with 1,000 homes each
>>>> with 1 Gbps links to have a terabit of uplink capacity. But it also should
>>>> have a lot more than 10 Gbps, IMHO. Unfortunately, most neighborhoods I
>>>> have seen are closer to the latter than the former.
>>>>
>>>> Finally, this could quickly devolve into finger pointing. You say the
>>>> CDNs bear some responsibility? They may well respond that the large
>>>> broadband providers ask for cash to interconnect - but still require the
>>>> CDNs to do all the work. The CDNs did not create the content, or tell the
>>>> users which content to pull. When I pay $NATIONAL_PROVIDER, I expect them
>>>> to provide me with access to the Internet. Not just to the content that
>>>> pays that provider.
>>>>
>>>> Personally, I have zero problems with the ISPs saying “give me a cache
>>>> to put here with this sized uplink” or “please deliver to these users over
>>>> this xconn / IX / whatever”. I have a huge problem with the ISPs blaming
>>>> the ISPs for delivering what the ISP’s users request.
>>>>
>>>> Of course, this could all be solved if there were more competition in
>>>> broadband in the US (and many other countries). But that is a totally
>>>> different 10,000 post thread (that we have had many dozens of times).
>>>>
>>>> --
>>>> TTFN,
>>>> patrick
>>>>
>>>> On Apr 1, 2021, at 3:53 PM, Matt Erculiani <merculiani at gmail.com>
>>>> wrote:
>>>>
>>>> Niels,
>>>>
>>>> I think to clarify Jean's point, when you buy a 300mbps circuit, you're
>>>> paying for 300mbps of *internet *access.
>>>>
>>>> That does not mean that a network should (and in this case small-medium
>>>> ones simply can't) build all of their capacity to service a large number of
>>>> customer circuits at line rate at the same time for an extended
>>>> period, ESPECIALLY to the exact same endpoint. It's just not economically
>>>> reasonable to expect that. Remember we're talking about residential service
>>>> here, not enterprise circuits.
>>>>
>>>> Therefore, how do you prevent this spike of [insert large number here]
>>>> gigabits traversing the network at the same time from causing issues? Build
>>>> more network? That sounds easy, but there are plenty of legitimate reasons
>>>> why ISPs can't or don't want to do that, particularly for an event that
>>>> only occurs once per quarter or so.
>>>>
>>>> Does Akamai bear some burden here to make these rollouts less
>>>> troublesome for the ISPs they traverse through the last mile(s)? IMO yes,
>>>> yes they do. When you're doing something new and unprecedented, as Akamai
>>>> frequently brags about on Twitter, like having rapid, bursty growth of
>>>> traffic, you need to consider that just because you can generate it,
>>>> doesn't mean it can be delivered.  They've gotta be more sophisticated than
>>>> a bunch of servers with SSD arrays, ramdisks, and 100 gig interfaces, so
>>>> there's no excuse for them here to just blindly fill every link they have
>>>> after sitting idle for weeks/months at a time and expect everything to come
>>>> out alright and nobody to complain about it.
>>>>
>>>> On Thu, Apr 1, 2021 at 1:21 PM Niels Bakker <niels=nanog at bakker.net>
>>>> wrote:
>>>>
>>>>> * nanog at nanog.org (Jean St-Laurent via NANOG) [Thu 01 Apr 2021, 21:03
>>>>> CEST]:
>>>>> >An artificial roll out penalty somehow? Probably not at the ISP
>>>>> >level, but more at the game level. Well, ISP could also have some
>>>>> >mechanisms to reduce the impact or even Akamai could force a
>>>>> >progressive roll out.
>>>>>
>>>>> It's an online game. You can't play the game with outdated assets.
>>>>> You'd not see walls where other players would, for example.
>>>>>
>>>>> What you're suggesting is the ability of ISPs to market Internet
>>>>> access
>>>>> at a certain speed but not have to deliver it based on conditions they
>>>>> create.
>>>>>
>>>>>
>>>>>         -- Niels.
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Erculiani
>>>> ERCUL-ARIN
>>>>
>>>>
>>>>
>>>
>>> --
>>> Matt Erculiani
>>> ERCUL-ARIN
>>>
>>
>
> --
> Matt Erculiani
> ERCUL-ARIN
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210401/62050004/attachment.html>