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 <merculi...@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 <beec...@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 <merculi...@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 <patr...@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 <merculi...@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=na...@bakker.net> >>>> wrote: >>>> >>>>> * nanog@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 >
