COVID-19 vs. our Networks

Sat Mar 14 18:49:49 UTC 2020

The access facility and the underlying long haul 
are telecommunications services.  The application 
provided using that facility may or may not 
be.  The congestion you were experiencing was not 
with the telecommunications facility itself, but 
with the application running on it, and was as 
you state, outside of your network - on a CDN 
hosted service.  Your argument is with your third 
party hosted service.   Their argument is with their CDN.

Internet exchange points are not 
regulated.  Interconnections between ISPs and 
CDNs are private agreements, and are always at 
risk of congestion and commercial dispute between 
the parties.  There is a long history of this.

If you have a direct layer 2 or 3 private line to 
your hosted service provider's CDN, and it was 
not performing as per the SLA, then you need to take that up with them.

If the underlying telecommunications facility 
failed, and was classified as critical 
infrastructure, and not restored in a timely 
manner, then you need to take that up with the provider of that infrastructure.

I'm not trying to be difficult, but the fact 
remains that there is a distinction between 
telecommunications services, and Internet 
services.  The fact that Internet services (and 
I'm not talking about any one particular DIA 
circuit, but the rather the global network of 
networks) work so well most of the time, such 
that people tend to start treating it as a 
substitute for telecommunications services is pretty impressive.

There are cost/benefit tradeoffs for using cloud 
hosted services and public Internet 
infrastructure.  You save money by not operating 
the data centre yourself, but you pay for it in 
reliability.   Your organization may have made 
that choice, but to say that because you chose to 
put critical applications on Internet 
infrastructure, other users of the Internet 
should take a back seat to your needs seems to be 
a bit of a stretch.   Again, if your provider 
sold this to you as something that was NOT 
relying on public Internet, and was Layer 2/3 
private managed services with dedicated 
bandwidth, then you need to have a conversation with them.

At 02:01 PM 14/03/2020, Mike Bolitho wrote:
>First of all, we use a mixture of layer 2/3 
>private lines and DIA circuits. You don't know 
>our infrastructure, stop being condescending. It 
>goes against the spirit of this mailing list.
>
>Second, yes, the Internet is protected. Both 
>public and private lines. I know this because we 
>have TSP coded circuits and I spent four years 
>at a Tier I ISP servicing TSP coded circuits
>
>Third, the trouble we had was a third party 
>service having congestion issues. They are 
>hosted by the same CDN as Call of Duty. The 
>problem was both outside of our control and our 
>third party service'sÂ control. The chokepoint 
>was between ISPs/IXPs and the CDN. I've seen 
>this time and time again while working at the 
>aforementionedÂ ISP. Saturated links on 
>ISP/IXP/CDN networks. This is where the TSP code 
>comes in. In this day and age of cloud services, 
>it is financially unfeasible for every company 
>to have a private line to every single cloudÂ 
>provider. That's preposterousÂ to even suggest.
>
>- Mike Bolitho
>
>
>On Sat, Mar 14, 2020 at 10:40 AM Clayton 
>Zekelman <<mailto:clayton at mnsi.net>clayton at mnsi.net> wrote:
>
>
>The Internet is not a telecommunications 
>service, according to your FCC.Â  If you want 
>predictability, buy WAN circuits, not Internet 
>circuits.Â Â  If your provider is co-mingling 
>Internet and WAN traffic (i.e. circuits with 
>defined endpoints vs. public Internet or VPN), 
>then you need to talk to them about their prioritization.
>
>If you have mission critical applications, put 
>them on mission critical infrastructure, not the public Internet.
>
>Oh, that's right - Internet circuits are cheaper than WAN circuits
>

-- 

Clayton Zekelman
Managed Network Systems Inc. (MNSi)
3363 Tecumseh Rd. E
Windsor, Ontario
N8W 1H4

tel. 519-985-8410
fax. 519-985-8409        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200314/0ff82da6/attachment.html>