Re: COVID-19 vs. our Networks

[Mel Beckman]

I don’t think Netflix has any quality guarantees. So you’re SOL if you think 
there is some kind of legal recourse. I’d argue that 50% pay for 50% quality is 
illogical anyway. HD is 25% the quality of 4K. Yet you get virtually all of the 
value of the content, with only a sight reduction in detail. 

Personally, I don’t think now is the time to quibble about ethereal costs. We 
all need to roll up our sleeves, put our big boy pants on, and get the planet 
through this crisis.

 -mel 

> On Mar 19, 2020, at 10:02 PM, Keith Medcalf  wrote:
> 
> 
>> On Thursday, 19 March, 2020 10:07, Matt Hoppes 
>>  wrote:
>> 
>> Agreed... 720 or 1080 Netflix will work just as fine as 4K for the next
>> month or two.
> 
> As long as NetFlix lowers their prices proportionately with their reduced 
> level of service.  For example, if NetFlix decides they will only provide 
> "half-quality" service then they should only charge half price.
> 
> -- 
> The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
> lot about anticipated traffic volume.
> 
> 
> 

Re: COVID-19 vs. our Networks

[Mark Tinka]

On 20/Mar/20 09:19, Mel Beckman wrote:

> I don’t think Netflix has any quality guarantees. So you’re SOL if you think 
> there is some kind of legal recourse. I’d argue that 50% pay for 50% quality 
> is illogical anyway. HD is 25% the quality of 4K. Yet you get virtually all 
> of the value of the content, with only a sight reduction in detail. 
>
> Personally, I don’t think now is the time to quibble about ethereal costs. We 
> all need to roll up our sleeves, put our big boy pants on, and get the planet 
> through this crisis.

As I said on another list yesterday:

Overall, we've spent 3 decades building this global Internet. Time to
see if the child can stand on its own two webbed feet :-).

Mark.

Re: CISA: Guidance on the Essential Critical Infrastructure Workforce

[Heart Rate Var LF/HF==]

I hope they give them masks, and ideally total body coverage, one time 
use, like One Time Passwords.


I really hope it.

Lots of key workers here without masks.

I dont know whether you know the joke about going to war without 
weapons.  We did kid about Russians doing that in WWII, and about others 
in WW1.


If you do not have masks, please make mask yourself, do it yourself, 
tissue, elastics, its easy; cut a rear pocket from the jeans. Constalty 
wear it, but also when distanced from others remove it.  One can see to 
a longer distance than one can breath the virus spread.  But stay away 
and dont breath if mask down. It's also good to wear eye glasses, like 
'shades', to avoid virus intake by the eyes.


When one shows face to others its good, somebody can tell have seen that 
person.


If you do wear gloves then make sure you change them after each time you 
touched something.  Changing gloves involves a particular technique: 
whhen ungloving avoid touching the external side of glove with your skin.


Do not put your gloved hands in your elbow angle while waiting  
patiently and showing force (some security people wear gloves, then 
cough in elbow, and then display force by putting palms in elbow angle - 
'croiser les bras', french).


Alex

Le 20/03/2020 à 07:27, colin johnston a écrit :
UK gov notification of key worker status inc Telecommunication/Data 
Centre workers

https://www.gov.uk/government/publications/coronavirus-covid-19-maintaining-educational-provision/guidance-for-schools-colleges-and-local-authorities-on-maintaining-educational-provision

Col





On 19 Mar 2020, at 21:36, Sean Donelan > wrote:



The U.S. Cyber and Infrastructure Security Agency (part of the U.S. 
Department of Homeland Security) has issued new Guidance on the 
Essential Critical Infrastructure Workforce.


The memorandum is advisory, not presecriptive.  DHS is only one of 
several agencies assigned some National Essential Functions so it is 
not exhaustive list.  It looks like someone found the three-ring 
emergency plan binders. Sad its needed, but appreciative of the 
experts which helped write those planning documents over the years.



https://www.cisa.gov/publication/guidance-essential-critical-infrastructure
-workforce

[...]
The attached list identifies workers who conduct a range of 
operations and services that are essential to continued critical 
infrastructure viability, including staffing operations centers, 
maintaining and repairing critical infrastructure, operating call 
centers, working construction, and performing management functions, 
among others. The industries they support represent, but are not 
necessarily limited to, medical and healthcare, telecommunications, 
information technology systems, defense, food and agriculture, 
transportation and logistics, energy, water and wastewater, law 
enforcement, and public works.


We recognize that State, local, tribal, and territorial governments 
are ultimately in charge of implementing and executing response 
activities in communities under their jurisdiction, while the 
Federal Government is in a supporting role. As State and local 
communities consider


COVID-19-related restrictions, CISA is offering this list to assist 
prioritizing activities related to continuity of operations and 
incident response, including the appropriate movement of critical 
infrastructure workers within and between jurisdictions.


Accordingly, this list is advisory in nature. It is not, nor should 
it be considered to be, a federal directive or standard in and of 
itself.

[...]

RE: CISA: Guidance on the Essential Critical Infrastructure Workforce

[Ryland Kremeier]

This really depends on particulate size. A mask may only save you from touching 
your face. You are much better off just washing your hands constantly and 
keeping your distance as much as possible from others. Remove, wash your 
clothes, and shower immediately when you get home. Use hand sanitizers 
throughout the day and don't touch your face.

When wearing gloves, you DO NOT change them after you touch something. The 
objective is not to keep the gloves clean, but your hands; excessive changing 
of gloves will only lead to more particulate transfer onto your skin.

-- Ryland


From: NANOG  On Behalf Of 
Heart Rate Var LF/HF==
Sent: Friday, March 20, 2020 7:09 AM
To: nanog@nanog.org
Subject: Re: CISA: Guidance on the Essential Critical Infrastructure Workforce


I hope they give them masks, and ideally total body coverage, one time use, 
like One Time Passwords.

I really hope it.

Lots of key workers here without masks.

I dont know whether you know the joke about going to war without weapons.  We 
did kid about Russians doing that in WWII, and about others in WW1.

If you do not have masks, please make mask yourself, do it yourself, tissue, 
elastics, its easy; cut a rear pocket from the jeans.  Constalty wear it, but 
also when distanced from others remove it.  One can see to a longer distance 
than one can breath the virus spread.  But stay away and dont breath if mask 
down.  It's also good to wear eye glasses, like 'shades', to avoid virus intake 
by the eyes.

When one shows face to others its good, somebody can tell have seen that person.

If you do wear gloves then make sure you change them after each time you 
touched something.  Changing gloves involves a particular technique: whhen 
ungloving avoid touching the external side of glove with your skin.

Do not put your gloved hands in your elbow angle while waiting  patiently and 
showing force (some security people wear gloves, then cough in elbow, and then 
display force by putting palms in elbow angle - 'croiser les bras', french).

Alex
Le 20/03/2020 à 07:27, colin johnston a écrit :
UK gov notification of key worker status inc Telecommunication/Data Centre 
workers
https://www.gov.uk/government/publications/coronavirus-covid-19-maintaining-educational-provision/guidance-for-schools-colleges-and-local-authorities-on-maintaining-educational-provision

Col






On 19 Mar 2020, at 21:36, Sean Donelan 
mailto:s...@donelan.com>> wrote:


The U.S. Cyber and Infrastructure Security Agency (part of the U.S. Department 
of Homeland Security) has issued new Guidance on the Essential Critical 
Infrastructure Workforce.

The memorandum is advisory, not presecriptive.  DHS is only one of several 
agencies assigned some National Essential Functions so it is not exhaustive 
list.  It looks like someone found the three-ring emergency plan binders. Sad 
its needed, but appreciative of the experts which helped write those planning 
documents over the years.


https://www.cisa.gov/publication/guidance-essential-critical-infrastructure
-workforce

[...]
The attached list identifies workers who conduct a range of operations and 
services that are essential to continued critical infrastructure viability, 
including staffing operations centers, maintaining and repairing critical 
infrastructure, operating call centers, working construction, and performing 
management functions, among others. The industries they support represent, but 
are not necessarily limited to, medical and healthcare, telecommunications, 
information technology systems, defense, food and agriculture, transportation 
and logistics, energy, water and wastewater, law enforcement, and public works.

We recognize that State, local, tribal, and territorial governments are 
ultimately in charge of implementing and executing response activities in 
communities under their jurisdiction, while the Federal Government is in a 
supporting role. As State and local communities consider

COVID-19-related restrictions, CISA is offering this list to assist 
prioritizing activities related to continuity of operations and incident 
response, including the appropriate movement of critical infrastructure workers 
within and between jurisdictions.

Accordingly, this list is advisory in nature. It is not, nor should it be 
considered to be, a federal directive or standard in and of itself.
[...]

Re: COVID-19 vs. our Networks

[Blake Hudson]

On 3/19/2020 12:22 PM, Mark Tinka wrote:


On 19/Mar/20 18:07, Matt Hoppes wrote:

Agreed... 720 or 1080 Netflix will work just as fine as 4K for the
next month or two.

Well, the article claims "Drop stream quality from HD". That means 4K,
1080p and 720p.

If you have an OCA on your network, how does this encourage consumers to
use the "extra bandwidth" for anything else?

Are we assuming we know how consumers want to spend their time now?

Mark.


Across several eyeball networks I'm not seeing any noticeable increase 
in peak (95%) demand between now and January. Since Netflix 
automatically scales down data rates in the event of congestion, the 
only thing I foresee forcing Netflix to reduce data rates [ahead of any 
congestion] would accomplish is causing excess link capacity to go 
unused (wasted). This sounds like a policy decision made without a 
technical argument... e.g. not a data driven decision, but a decision 
made out of fear or panic.

Re: COVID-19 vs. our Networks

[Mike Hammett]

Why in the world would they do that? 


Maybe waive the fees for the higher services, but you're not entitled to 
anything more than that. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Keith Medcalf"  
To: "NANOG"  
Sent: Friday, March 20, 2020 12:02:08 AM 
Subject: RE: COVID-19 vs. our Networks 


On Thursday, 19 March, 2020 10:07, Matt Hoppes 
 wrote: 

>Agreed... 720 or 1080 Netflix will work just as fine as 4K for the next 
>month or two. 

As long as NetFlix lowers their prices proportionately with their reduced level 
of service. For example, if NetFlix decides they will only provide 
"half-quality" service then they should only charge half price. 

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume. 

Re: COVID-19 vs. our Networks

[Mike Hammett]

Some of the pipes Netflix goes through is also used by other services that 
aren't as adaptable. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Blake Hudson"  
To: nanog@nanog.org 
Sent: Friday, March 20, 2020 8:32:45 AM 
Subject: Re: COVID-19 vs. our Networks 


On 3/19/2020 12:22 PM, Mark Tinka wrote: 
> 
> On 19/Mar/20 18:07, Matt Hoppes wrote: 
>> Agreed... 720 or 1080 Netflix will work just as fine as 4K for the 
>> next month or two. 
> Well, the article claims "Drop stream quality from HD". That means 4K, 
> 1080p and 720p. 
> 
> If you have an OCA on your network, how does this encourage consumers to 
> use the "extra bandwidth" for anything else? 
> 
> Are we assuming we know how consumers want to spend their time now? 
> 
> Mark. 

Across several eyeball networks I'm not seeing any noticeable increase 
in peak (95%) demand between now and January. Since Netflix 
automatically scales down data rates in the event of congestion, the 
only thing I foresee forcing Netflix to reduce data rates [ahead of any 
congestion] would accomplish is causing excess link capacity to go 
unused (wasted). This sounds like a policy decision made without a 
technical argument... e.g. not a data driven decision, but a decision 
made out of fear or panic. 

Re: CISA: Guidance on the Essential Critical Infrastructure Workforce

[Alexandre Petrescu]

LF/HF

Le 20/03/2020 à 13:48, Ryland Kremeier a écrit :


This really depends on particulate size. A mask may only save you from 
touching your face. You are much better off just washing your hands 
constantly and keeping your distance as much as possible from others. 
Remove, wash your clothes, and shower immediately when you get home. 
Use hand sanitizers throughout the day and don’t touch your face.


When wearing gloves, you DO NOT change them after you touch something. 
The objective is not to keep the gloves clean, but your hands; 
excessive changing of gloves will only lead to more particulate 
transfer onto your skin.




In France I must show a paper (not smartphone) printed permit, each 
sortie one different paper.  The receiver of it (police) takes it in 
his/her gloved hands then s/he passes it back to me. I do not have 
gloves.  I wished the receiver did not use the same gloves for each 
pereson who passes by and delivers that paper to him.


TRansmission should be analyzed.

Alex


-- Ryland

*From:* NANOG  
*On Behalf Of *Heart Rate Var LF/HF==

*Sent:* Friday, March 20, 2020 7:09 AM
*To:* nanog@nanog.org
*Subject:* Re: CISA: Guidance on the Essential Critical Infrastructure 
Workforce


I hope they give them masks, and ideally total body coverage, one time 
use, like One Time Passwords.


I really hope it.

Lots of key workers here without masks.

I dont know whether you know the joke about going to war without 
weapons.  We did kid about Russians doing that in WWII, and about 
others in WW1.


If you do not have masks, please make mask yourself, do it yourself, 
tissue, elastics, its easy; cut a rear pocket from the jeans.  
Constalty wear it, but also when distanced from others remove it.  One 
can see to a longer distance than one can breath the virus spread.  
But stay away and dont breath if mask down.  It's also good to wear 
eye glasses, like 'shades', to avoid virus intake by the eyes.


When one shows face to others its good, somebody can tell have seen 
that person.


If you do wear gloves then make sure you change them after each time 
you touched something.  Changing gloves involves a particular 
technique: whhen ungloving avoid touching the external side of glove 
with your skin.


Do not put your gloved hands in your elbow angle while waiting  
patiently and showing force (some security people wear gloves, then 
cough in elbow, and then display force by putting palms in elbow angle 
- 'croiser les bras', french).


Alex

Le 20/03/2020 à 07:27, colin johnston a écrit :

UK gov notification of key worker status inc
Telecommunication/Data Centre workers


https://www.gov.uk/government/publications/coronavirus-covid-19-maintaining-educational-provision/guidance-for-schools-colleges-and-local-authorities-on-maintaining-educational-provision

Col





On 19 Mar 2020, at 21:36, Sean Donelan mailto:s...@donelan.com>> wrote:


The U.S. Cyber and Infrastructure Security Agency (part of
the U.S. Department of Homeland Security) has issued new
Guidance on the Essential Critical Infrastructure Workforce.

The memorandum is advisory, not presecriptive.  DHS is
only one of several agencies assigned some National
Essential Functions so it is not exhaustive list.  It
looks like someone found the three-ring emergency plan
binders. Sad its needed, but appreciative of the experts
which helped write those planning documents over the years.



https://www.cisa.gov/publication/guidance-essential-critical-infrastructure
-workforce

[...]
The attached list identifies workers who conduct a range
of operations and services that are essential to continued
critical infrastructure viability, including staffing
operations centers, maintaining and repairing critical
infrastructure, operating call centers, working
construction, and performing management functions, among
others. The industries they support represent, but are not
necessarily limited to, medical and healthcare,
telecommunications, information technology systems,
defense, food and agriculture, transportation and
logistics, energy, water and wastewater, law enforcement,
and public works.

We recognize that State, local, tribal, and territorial
governments are ultimately in charge of implementing and
executing response activities in communities under their
jurisdiction, while the Federal Government is in a
supporting role. As State and local communities consider

COVID-19-related restrictions, CISA is offering this list
to assist prioritizing activities related to continuity of
operations and incident response, including the
appro

Re: COVID-19 vs. our Networks

[Blake Hudson]

Yes, but does that matter? If there's extra capacity on the link, 
Netflix runs at full rate. If there is not extra capacity Netflix rates 
down to prevent congestion. While streaming video (including Netflix) 
uses a lot of bandwidth, I don't see Netflix causing congestion. It gets 
a bad wrap, and I think that's unfair because Netflix is actually really 
efficient and really conscientious compared to others.


On 3/20/2020 8:52 AM, Mike Hammett wrote:
Some of the pipes Netflix goes through is also used by other services 
that aren't as adaptable.




-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


*From: *"Blake Hudson" 
*To: *nanog@nanog.org
*Sent: *Friday, March 20, 2020 8:32:45 AM
*Subject: *Re: COVID-19 vs. our Networks


On 3/19/2020 12:22 PM, Mark Tinka wrote:
>
> On 19/Mar/20 18:07, Matt Hoppes wrote:
>> Agreed... 720 or 1080 Netflix will work just as fine as 4K for the
>> next month or two.
> Well, the article claims "Drop stream quality from HD". That means 4K,
> 1080p and 720p.
>
> If you have an OCA on your network, how does this encourage consumers to
> use the "extra bandwidth" for anything else?
>
> Are we assuming we know how consumers want to spend their time now?
>
> Mark.

Across several eyeball networks I'm not seeing any noticeable increase
in peak (95%) demand between now and January. Since Netflix
automatically scales down data rates in the event of congestion, the
only thing I foresee forcing Netflix to reduce data rates [ahead of any
congestion] would accomplish is causing excess link capacity to go
unused (wasted). This sounds like a policy decision made without a
technical argument... e.g. not a data driven decision, but a decision
made out of fear or panic.

Re: COVID-19 vs. our Networks

[Mike Hammett]

It's one of those most important things that matters. 


The end user likely won't notice the difference between 4k and 720p. They also 
aren't likely to notice the transition from one to the other. 


The person on the VPN, VoIP call, video conference, video game, etc. will very 
much notice the congested link, even if it's only a few seconds. 




Yes, Netflix video is very efficient, if not the most efficient. They're also 
one of if not the largest slingers of bits on the Internet. Small changes in 
usage of such a huge player totally eclipse most other usages on the Internet. 


https://help.netflix.com/en/node/306 


Netflix recommends 25 megs for Ultra HD, while only 5 megs for HD. That's a 5x 
difference in something people likely won't notice and would make a big 
difference on the additional VPN, VoIP, video conferencing, etc. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Blake Hudson"  
To: nanog@nanog.org 
Sent: Friday, March 20, 2020 9:01:18 AM 
Subject: Re: COVID-19 vs. our Networks 

Yes, but does that matter? If there's extra capacity on the link, Netflix runs 
at full rate. If there is not extra capacity Netflix rates down to prevent 
congestion. While streaming video (including Netflix) uses a lot of bandwidth, 
I don't see Netflix causing congestion. It gets a bad wrap, and I think that's 
unfair because Netflix is actually really efficient and really conscientious 
compared to others. 


On 3/20/2020 8:52 AM, Mike Hammett wrote: 



Some of the pipes Netflix goes through is also used by other services that 
aren't as adaptable. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Blake Hudson"  
To: nanog@nanog.org 
Sent: Friday, March 20, 2020 8:32:45 AM 
Subject: Re: COVID-19 vs. our Networks 


On 3/19/2020 12:22 PM, Mark Tinka wrote: 
> 
> On 19/Mar/20 18:07, Matt Hoppes wrote: 
>> Agreed... 720 or 1080 Netflix will work just as fine as 4K for the 
>> next month or two. 
> Well, the article claims "Drop stream quality from HD". That means 4K, 
> 1080p and 720p. 
> 
> If you have an OCA on your network, how does this encourage consumers to 
> use the "extra bandwidth" for anything else? 
> 
> Are we assuming we know how consumers want to spend their time now? 
> 
> Mark. 

Across several eyeball networks I'm not seeing any noticeable increase 
in peak (95%) demand between now and January. Since Netflix 
automatically scales down data rates in the event of congestion, the 
only thing I foresee forcing Netflix to reduce data rates [ahead of any 
congestion] would accomplish is causing excess link capacity to go 
unused (wasted). This sounds like a policy decision made without a 
technical argument... e.g. not a data driven decision, but a decision 
made out of fear or panic. 

RE: COVID-19 vs. peering wars

[Steve Mikulasik via NANOG]

In Canada the CRTC really needs to get on Canadian ISPs about peering very 
liberally at IXs in each province. I know of one major institution right now 
that would have a major work from home issue resolved if one big ISP would peer 
with one big tier 1 in the IX they are both located at in the same province. 
Instead traffic needs to flow across the country or to the USA to get back to 
the same city.


From: NANOG  On Behalf Of Matthew Petach
Sent: Thursday, March 19, 2020 4:15 PM
To: Mike Bolitho 
Cc: NANOG 
Subject: COVID-19 vs. peering wars

CAUTION: This email originated from outside of Civeo.
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.



On Thu, Mar 19, 2020 at 10:27 AM Mike Bolitho 
mailto:mikeboli...@gmail.com>> wrote:
Restoration:

The repair or returning to service of one or more telecommunications services 
that have experienced a service outage or are unusable for any reason, 
including a damaged or impaired telecommunications facility. Such repair or 
returning to service may be done by patching, rerouting, substitution of 
component parts or pathways, and other means, as determined necessary by a 
service vendor.

https://www.cisa.gov/sites/default/files/publications/OEC%20TSP%20Operations%20Guide%20Final%2012062016_FINAL%20508C.pdf

My understanding, and what we did while I worked for a Tier I ISP, was that 
even for degraded circuits we had to do everything in our power to restore to 
full operations. If capacity is an issue and causes TSP coded DIA circuits to 
be unusable then that falls under the "any reason" clause of that line.

- Mike Bolitho

If you're going to bang that drum, the place you're going to get the most 
buck-for-your-bang is using it to force better cooperation between ISPs.

It appears that baking cakes was not sufficient to get recalcitrant players to 
work together.

https://www.flickr.com/photos/mpetach/4031195041

Perhaps a global pandemic may be sufficient to have government begin to 
*compel* networks to interconnect at locations at which they share common 
peering infrastructure?

If you're worried about congestion and performance, that would be the place to 
start pushing.

Matt
staying safely at home away from the flame-fest that may ensue from this.   ^_^;

Re: COVID-19 vs. peering wars

[Sadiq Saif]

On Fri, 20 Mar 2020, at 10:31, Steve Mikulasik via NANOG wrote:
>  
> In Canada the CRTC really needs to get on Canadian ISPs about peering 
> very liberally at IXs in each province. I know of one major institution 
> right now that would have a major work from home issue resolved if one 
> big ISP would peer with one big tier 1 in the IX they are both located 
> at in the same province. Instead traffic needs to flow across the 
> country or to the USA to get back to the same city.

**cough** Bell Canada **cough**.

-- 
  Sadiq Saif
  https://sadiqsaif.com/

Re: COVID-19 vs. our Networks

[Tom Beecher]

It is something that matters, because it has the potential to set a
dangerous precedent.

If you say "$Service should reduce their bit rates because this is an
emergency!" , I guarantee that exact same argument will be made well after
this crisis has passed with a different definition of "emergency", and
adding on "well it's an emergency to me!".

Some of the pipes Netflix goes through is also used by other services that
> aren't as adaptable.
>

And how is that Netflix's responsibility? They have already taken action to
ramp down bitrates when they detect congestion. Why should other
applications be able to say piss off, I don't want to? Didn't we just have
a 10 year net neutrality argument that we're not supposed to want to treat
the bits differently?

On Fri, Mar 20, 2020 at 10:17 AM Mike Hammett  wrote:

> It's one of those most important things that matters.
>
> The end user likely won't notice the difference between 4k and 720p. They
> also aren't likely to notice the transition from one to the other.
>
> The person on the VPN, VoIP call, video conference, video game, etc. will
> very much notice the congested link, even if it's only a few seconds.
>
>
> Yes, Netflix video is very efficient, if not the most efficient. They're
> also one of if not the largest slingers of bits on the Internet. Small
> changes in usage of such a huge player totally eclipse most other usages on
> the Internet.
>
> https://help.netflix.com/en/node/306
>
> Netflix recommends 25 megs for Ultra HD, while only 5 megs for HD. That's
> a 5x difference in something people likely won't notice and would make a
> big difference on the additional VPN, VoIP, video conferencing, etc.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Blake Hudson" 
> *To: *nanog@nanog.org
> *Sent: *Friday, March 20, 2020 9:01:18 AM
> *Subject: *Re: COVID-19 vs. our Networks
>
> Yes, but does that matter? If there's extra capacity on the link, Netflix
> runs at full rate. If there is not extra capacity Netflix rates down to
> prevent congestion. While streaming video (including Netflix) uses a lot of
> bandwidth, I don't see Netflix causing congestion. It gets a bad wrap, and
> I think that's unfair because Netflix is actually really efficient and
> really conscientious compared to others.
>
> On 3/20/2020 8:52 AM, Mike Hammett wrote:
>
> Some of the pipes Netflix goes through is also used by other services that
> aren't as adaptable.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Blake Hudson"  
> *To: *nanog@nanog.org
> *Sent: *Friday, March 20, 2020 8:32:45 AM
> *Subject: *Re: COVID-19 vs. our Networks
>
>
> On 3/19/2020 12:22 PM, Mark Tinka wrote:
> >
> > On 19/Mar/20 18:07, Matt Hoppes wrote:
> >> Agreed... 720 or 1080 Netflix will work just as fine as 4K for the
> >> next month or two.
> > Well, the article claims "Drop stream quality from HD". That means 4K,
> > 1080p and 720p.
> >
> > If you have an OCA on your network, how does this encourage consumers to
> > use the "extra bandwidth" for anything else?
> >
> > Are we assuming we know how consumers want to spend their time now?
> >
> > Mark.
>
> Across several eyeball networks I'm not seeing any noticeable increase
> in peak (95%) demand between now and January. Since Netflix
> automatically scales down data rates in the event of congestion, the
> only thing I foresee forcing Netflix to reduce data rates [ahead of any
> congestion] would accomplish is causing excess link capacity to go
> unused (wasted). This sounds like a policy decision made without a
> technical argument... e.g. not a data driven decision, but a decision
> made out of fear or panic.
>
>
>
>
>

Re: COVID-19 vs. our Networks

[Mel Beckman]

If you say "$Service should reduce their bit rates because this is an 
emergency!" , I guarantee that exact same argument will be made well after this 
crisis has passed with a different definition of "emergency", and adding on 
"well it's an emergency to me!"

Well, that’s a silly argument. Do you think people can’t tell the difference 
between a once-in-a-lifetime pandemic and somebody who’s having a “personal 
emergency”?

 -mel

On Mar 20, 2020, at 7:43 AM, Tom Beecher  wrote:


It is something that matters, because it has the potential to set a dangerous 
precedent.

If you say "$Service should reduce their bit rates because this is an 
emergency!" , I guarantee that exact same argument will be made well after this 
crisis has passed with a different definition of "emergency", and adding on 
"well it's an emergency to me!".

Some of the pipes Netflix goes through is also used by other services that 
aren't as adaptable.

And how is that Netflix's responsibility? They have already taken action to 
ramp down bitrates when they detect congestion. Why should other applications 
be able to say piss off, I don't want to? Didn't we just have a 10 year net 
neutrality argument that we're not supposed to want to treat the bits 
differently?

On Fri, Mar 20, 2020 at 10:17 AM Mike Hammett 
mailto:na...@ics-il.net>> wrote:
It's one of those most important things that matters.

The end user likely won't notice the difference between 4k and 720p. They also 
aren't likely to notice the transition from one to the other.

The person on the VPN, VoIP call, video conference, video game, etc. will very 
much notice the congested link, even if it's only a few seconds.


Yes, Netflix video is very efficient, if not the most efficient. They're also 
one of if not the largest slingers of bits on the Internet. Small changes in 
usage of such a huge player totally eclipse most other usages on the Internet.

https://help.netflix.com/en/node/306

Netflix recommends 25 megs for Ultra HD, while only 5 megs for HD. That's a 5x 
difference in something people likely won't notice and would make a big 
difference on the additional VPN, VoIP, video conferencing, etc.



-
Mike Hammett
Intelligent Computing Solutions
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
Midwest Internet Exchange
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
The Brothers WISP
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png]

From: "Blake Hudson" mailto:bl...@ispn.net>>
To: nanog@nanog.org
Sent: Friday, March 20, 2020 9:01:18 AM
Subject: Re: COVID-19 vs. our Networks

Yes, but does that matter? If there's extra capacity on the link, Netflix runs 
at full rate. If there is not extra capacity Netflix rates down to prevent 
congestion. While streaming video (including Netflix) uses a lot of bandwidth, 
I don't see Netflix causing congestion. It gets a bad wrap, and I think that's 
unfair because Netflix is actually really efficient and really conscientious 
compared to others.

On 3/20/2020 8:52 AM, Mike Hammett wrote:
Some of the pipes Netflix goes through is also used by other services that 
aren't as adaptable.



-
Mike Hammett
Intelligent Computing Solutions
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
Midwest Internet Exchange
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png]
The Brothers WISP
[http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/youtubeicon.png]

From: "Blake Hudson" 

Re: COVID-19 vs. our Networks

[Blake Hudson]

Citing 25M may be a bit of a stretch since A) 4k is reserved for ISPs 
with a local cache (last time I checked), B) many (most?) Netflix 
customers are not on 4k equipment, C) 4k requires a premium subscription 
to Netflix at additional cost that not all customers have, D) the 
customer must have ~25M or above service and not be experiencing 
congestion on the path between the local Netflix cache and the 
customer's equipment, and E) if even one of the above is not true the 
Netflix user will typically receive a 3-5Mbps stream, depending on the 
device and connection performance.


On the networks I monitor, forcing a ~3Mbps or lower Netflix stream 
would have the effect of lowing the peak rate in the high demand hour, 
wasting available equipment and capacity. It would not have the effect 
of  improving VPN, VoIP, or video conferencing performance during the 
hours that those applications are typically used and I would wager that 
it would not have an appreciable effect on those applications even 
during peak usage periods. If there were a WiFi or similar issue within 
a specific household, the best way to address that is within the 
household (either turning off unneeded devices, moving high demand 
devices closer to the AP or wiring them, or upgrading to current WiFi 
technology).


--Blake


On 3/20/2020 9:15 AM, Mike Hammett wrote:

It's one of those most important things that matters.

The end user likely won't notice the difference between 4k and 720p. 
They also aren't likely to notice the transition from one to the other.


The person on the VPN, VoIP call, video conference, video game, etc. 
will very much notice the congested link, even if it's only a few seconds.



Yes, Netflix video is very efficient, if not the most efficient. 
They're also one of if not the largest slingers of bits on the 
Internet. Small changes in usage of such a huge player totally eclipse 
most other usages on the Internet.


https://help.netflix.com/en/node/306

Netflix recommends 25 megs for Ultra HD, while only 5 megs for HD. 
That's a 5x difference in something people likely won't notice and 
would make a big difference on the additional VPN, VoIP, video 
conferencing, etc.




-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


*From: *"Blake Hudson" 
*To: *nanog@nanog.org
*Sent: *Friday, March 20, 2020 9:01:18 AM
*Subject: *Re: COVID-19 vs. our Networks

Yes, but does that matter? If there's extra capacity on the link, 
Netflix runs at full rate. If there is not extra capacity Netflix 
rates down to prevent congestion. While streaming video (including 
Netflix) uses a lot of bandwidth, I don't see Netflix causing 
congestion. It gets a bad wrap, and I think that's unfair because 
Netflix is actually really efficient and really conscientious compared 
to others.


On 3/20/2020 8:52 AM, Mike Hammett wrote:

Some of the pipes Netflix goes through is also used by other
services that aren't as adaptable.



-
Mike Hammett
Intelligent Computing Solutions 


Midwest Internet Exchange 


The Brothers WISP 



*From: *"Blake Hudson" 
*To: *nanog@nanog.org
*Sent: *Friday, March 20, 2020 8:32:45 AM
*Subject: *Re: COVID-19 vs. our Networks


On 3/19/2020 12:22 PM, Mark Tinka wrote:
>
> On 19/Mar/20 18:07, Matt Hoppes wrote:
>> Agreed... 720 or 1080 Netflix will work just as fine as 4K for the
>> next month or two.
> Well, the article claims "Drop stream quality from HD". That
means 4K,
> 1080p and 720p.
>
> If you have an OCA on your network, how does this encourage
consumers to
> use the "extra bandwidth" for anything else?
>
> Are we assuming we know how consumers want to spend their time now?
>
> Mark.

Across several eyeball ne

Re: COVID-19 vs. our Networks

[Tom Beecher]

I think people can tell the difference just fine.

But get lawyers involved on what the word 'emergency' means, then watch the
fun.

On Fri, Mar 20, 2020 at 10:47 AM Mel Beckman  wrote:

>
> If you say "$Service should reduce their bit rates because this is an
> emergency!" , I guarantee that exact same argument will be made well after
> this crisis has passed with a different definition of "emergency", and
> adding on "well it's an emergency to me!"
>
>
> Well, that’s a silly argument. Do you think people can’t tell the
> difference between a once-in-a-lifetime pandemic and somebody who’s having
> a “personal emergency”?
>
>  -mel
>
> On Mar 20, 2020, at 7:43 AM, Tom Beecher  wrote:
>
> 
> It is something that matters, because it has the potential to set a
> dangerous precedent.
>
> If you say "$Service should reduce their bit rates because this is an
> emergency!" , I guarantee that exact same argument will be made well after
> this crisis has passed with a different definition of "emergency", and
> adding on "well it's an emergency to me!".
>
> Some of the pipes Netflix goes through is also used by other services that
>> aren't as adaptable.
>>
>
> And how is that Netflix's responsibility? They have already taken action
> to ramp down bitrates when they detect congestion. Why should other
> applications be able to say piss off, I don't want to? Didn't we just have
> a 10 year net neutrality argument that we're not supposed to want to treat
> the bits differently?
>
> On Fri, Mar 20, 2020 at 10:17 AM Mike Hammett  wrote:
>
>> It's one of those most important things that matters.
>>
>> The end user likely won't notice the difference between 4k and 720p. They
>> also aren't likely to notice the transition from one to the other.
>>
>> The person on the VPN, VoIP call, video conference, video game, etc. will
>> very much notice the congested link, even if it's only a few seconds.
>>
>>
>> Yes, Netflix video is very efficient, if not the most efficient. They're
>> also one of if not the largest slingers of bits on the Internet. Small
>> changes in usage of such a huge player totally eclipse most other usages on
>> the Internet.
>>
>> https://help.netflix.com/en/node/306
>>
>> Netflix recommends 25 megs for Ultra HD, while only 5 megs for HD. That's
>> a 5x difference in something people likely won't notice and would make a
>> big difference on the additional VPN, VoIP, video conferencing, etc.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>> --
>> *From: *"Blake Hudson" 
>> *To: *nanog@nanog.org
>> *Sent: *Friday, March 20, 2020 9:01:18 AM
>> *Subject: *Re: COVID-19 vs. our Networks
>>
>> Yes, but does that matter? If there's extra capacity on the link, Netflix
>> runs at full rate. If there is not extra capacity Netflix rates down to
>> prevent congestion. While streaming video (including Netflix) uses a lot of
>> bandwidth, I don't see Netflix causing congestion. It gets a bad wrap, and
>> I think that's unfair because Netflix is actually really efficient and
>> really conscientious compared to others.
>>
>> On 3/20/2020 8:52 AM, Mike Hammett wrote:
>>
>> Some of the pipes Netflix goes through is also used by other services
>> that aren't as adaptable.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>> --
>> *From: *"Blake Hudson"  
>> *To: *nanog@nanog.org
>> *Sent: *Friday, March 20, 2020 8:32:45 AM
>> *Subject: *Re: COVID-19 vs. our Networks
>>
>>
>> On 3/19/2020 12:22 PM, Mark Tinka wrote:
>> >
>> > On 19/Mar/20 18:07, Matt Hoppes wrote:
>> >> Agreed... 720 or 1080 Netflix will work just as fine as 4K for the
>> >> next month or two.
>> > Well, the article claims "Drop stream quality from HD". That means 4K,
>> > 1080p and 720p.
>> >
>> > If you have an O

Re: COVID-19 vs. our Networks

[Mike Hammett]

Because they're trying to be a responsible Internet citizen instead of just 
telling everyone else to bugger off. 


Perhaps if more entities tried to be responsible instead of entitled, the 
Internet wouldn't be as bad as it is? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Tom Beecher"  
To: "Mike Hammett"  
Cc: "Blake Hudson" , "NANOG"  
Sent: Friday, March 20, 2020 9:41:49 AM 
Subject: Re: COVID-19 vs. our Networks 


It is something that matters, because it has the potential to set a dangerous 
precedent. 


If you say "$Service should reduce their bit rates because this is an 
emergency!" , I guarantee that exact same argument will be made well after this 
crisis has passed with a different definition of "emergency", and adding on 
"well it's an emergency to me!". 



Some of the pipes Netflix goes through is also used by other services that 
aren't as adaptable. 





And how is that Netflix's responsibility? They have already taken action to 
ramp down bitrates when they detect congestion. Why should other applications 
be able to say piss off, I don't want to? Didn't we just have a 10 year net 
neutrality argument that we're not supposed to want to treat the bits 
differently? 


On Fri, Mar 20, 2020 at 10:17 AM Mike Hammett < na...@ics-il.net > wrote: 




It's one of those most important things that matters. 


The end user likely won't notice the difference between 4k and 720p. They also 
aren't likely to notice the transition from one to the other. 


The person on the VPN, VoIP call, video conference, video game, etc. will very 
much notice the congested link, even if it's only a few seconds. 




Yes, Netflix video is very efficient, if not the most efficient. They're also 
one of if not the largest slingers of bits on the Internet. Small changes in 
usage of such a huge player totally eclipse most other usages on the Internet. 


https://help.netflix.com/en/node/306 


Netflix recommends 25 megs for Ultra HD, while only 5 megs for HD. That's a 5x 
difference in something people likely won't notice and would make a big 
difference on the additional VPN, VoIP, video conferencing, etc. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 



From: "Blake Hudson" < bl...@ispn.net > 
To: nanog@nanog.org 
Sent: Friday, March 20, 2020 9:01:18 AM 
Subject: Re: COVID-19 vs. our Networks 

Yes, but does that matter? If there's extra capacity on the link, Netflix runs 
at full rate. If there is not extra capacity Netflix rates down to prevent 
congestion. While streaming video (including Netflix) uses a lot of bandwidth, 
I don't see Netflix causing congestion. It gets a bad wrap, and I think that's 
unfair because Netflix is actually really efficient and really conscientious 
compared to others. 


On 3/20/2020 8:52 AM, Mike Hammett wrote: 



Some of the pipes Netflix goes through is also used by other services that 
aren't as adaptable. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 



From: "Blake Hudson"  
To: nanog@nanog.org 
Sent: Friday, March 20, 2020 8:32:45 AM 
Subject: Re: COVID-19 vs. our Networks 


On 3/19/2020 12:22 PM, Mark Tinka wrote: 
> 
> On 19/Mar/20 18:07, Matt Hoppes wrote: 
>> Agreed... 720 or 1080 Netflix will work just as fine as 4K for the 
>> next month or two. 
> Well, the article claims "Drop stream quality from HD". That means 4K, 
> 1080p and 720p. 
> 
> If you have an OCA on your network, how does this encourage consumers to 
> use the "extra bandwidth" for anything else? 
> 
> Are we assuming we know how consumers want to spend their time now? 
> 
> Mark. 

Across several eyeball networks I'm not seeing any noticeable increase 
in peak (95%) demand between now and January. Since Netflix 
automatically scales down data rates in the event of congestion, the 
only thing I foresee forcing Netflix to reduce data rates [ahead of any 
congestion] would accomplish is causing excess link capacity to go 
unused (wasted). This sounds like a policy decision made without a 
technical argument... e.g. not a data driven decision, but a decision 
made out of fear or panic. 

Re: COVID-19 vs. our Networks

[Mike Bolitho]

>
> "It is something that matters, because it has the potential to set a
> dangerous precedent."
>

Can we stop with this talk... around everything? We're literally living
through an unprecedented event right now. My 86 year old grandmother said
she's never seen anything like this in the US. My friends 94 year old
grandmother in Italy said she hasn't seen this since WWII. Nobody is going
to say "Well we did this during a global pandemic so we can now do it
because we feel like it". People will laugh them out of the room. I live in
Phoenix, the mayor shut down bars and restaurants (carryout only) in order
to help stop us from becoming Italy. One of our city councilmen was saying
the same thing: "This is martial law and sets bad precedent! We must open
everything up!" Of course, they then held a closed to the public meeting
because city council can't be exposed. The point is, the mayor isn't going
to do the same thing in six months on a whim because traffic on the freeway
is bad. Thankfully calmer heads prevailed and the rest of the council told
him to pound sand, at least for now.

Something that keeps happening on this mailing list over the last few weeks
is this tendency to try to take the "Moral high ground". And from way up
there people are looking at the whole topic from an idealistic point of
view like we live in some Network Operators Utopia with perfect conditions
where money doesn't exist and we can do whatever we want because there is
no upper management. We should be having a practical conversation that sits
within the confines of reality. We don't have perfect networks built. We
don't have unlimited resources. We are facing a global pandemic. Money is
tight. In principle, I agree with what you guys are saying. But in reality,
we're going to have to bend our convictions in order to protect populations
from COVID-19. You will be changing your tune when your mother is sick and
can't get the care she needs because the system is overwhelmed because we
(communities, not just network operators) didn't do what was
necessary because of some idealistic hard line people drew in the sand.

- Mike Bolitho


On Fri, Mar 20, 2020 at 7:44 AM Tom Beecher  wrote:

> It is something that matters, because it has the potential to set a
> dangerous precedent.
>
> If you say "$Service should reduce their bit rates because this is an
> emergency!" , I guarantee that exact same argument will be made well after
> this crisis has passed with a different definition of "emergency", and
> adding on "well it's an emergency to me!".
>
> Some of the pipes Netflix goes through is also used by other services that
>> aren't as adaptable.
>>
>
> And how is that Netflix's responsibility? They have already taken action
> to ramp down bitrates when they detect congestion. Why should other
> applications be able to say piss off, I don't want to? Didn't we just have
> a 10 year net neutrality argument that we're not supposed to want to treat
> the bits differently?
>
> On Fri, Mar 20, 2020 at 10:17 AM Mike Hammett  wrote:
>
>> It's one of those most important things that matters.
>>
>> The end user likely won't notice the difference between 4k and 720p. They
>> also aren't likely to notice the transition from one to the other.
>>
>> The person on the VPN, VoIP call, video conference, video game, etc. will
>> very much notice the congested link, even if it's only a few seconds.
>>
>>
>> Yes, Netflix video is very efficient, if not the most efficient. They're
>> also one of if not the largest slingers of bits on the Internet. Small
>> changes in usage of such a huge player totally eclipse most other usages on
>> the Internet.
>>
>> https://help.netflix.com/en/node/306
>>
>> Netflix recommends 25 megs for Ultra HD, while only 5 megs for HD. That's
>> a 5x difference in something people likely won't notice and would make a
>> big difference on the additional VPN, VoIP, video conferencing, etc.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>> --
>> *From: *"Blake Hudson" 
>> *To: *nanog@nanog.org
>> *Sent: *Friday, March 20, 2020 9:01:18 AM
>> *Subject: *Re: COVID-19 vs. our Networks
>>
>> Yes, but does that matter? If there's extra capacity on the link, Netflix
>> runs at full rate. If there is not extra capacity Netflix rates down to
>> prevent congestion. While streaming video (including Netflix) uses a lot of
>> 

Re: COVID-19 vs. our Networks

[Blake Hudson]

Have you heard of the Patriot Act? Tom is correct that this does set a 
precedent of suppressing freedom of speech (I realize this is not a 
right in the EU like it is in US). "They that can give up essential 
liberty to purchase a little temporary safety, deserve neither liberty 
nor safety."



On 3/20/2020 10:10 AM, Mike Bolitho wrote:


"It is something that matters, because it has the potential to set
a dangerous precedent."


Can we stop with this talk... around everything? We're literally 
living through an unprecedented event right now. My 86 year old 
grandmother said she's never seen anything like this in the US. My 
friends 94 year old grandmother in Italy said she hasn't seen this 
since WWII. Nobody is going to say "Well we did this during a global 
pandemic so we can now do it because we feel like it". People will 
laugh them out of the room. I live in Phoenix, the mayor shut down 
bars and restaurants (carryout only) in order to help stop us from 
becoming Italy. One of our city councilmen was saying the same thing: 
"This is martial law and sets bad precedent! We must open everything 
up!" Of course, they then held a closed to the public meeting because 
city council can't be exposed. The point is, the mayor isn't going to 
do the same thing in six months on a whim because traffic on the 
freeway is bad. Thankfully calmer heads prevailed and the rest of the 
council told him to pound sand, at least for now.


Something that keeps happening on this mailing list over the last few 
weeks is this tendency to try to take the "Moral high ground". And 
from way up there people are looking at the whole topic from an 
idealistic point of view like we live in some Network Operators Utopia 
with perfect conditions where money doesn't exist and we can do 
whatever we want because there is no upper management. We should be 
having a practical conversation that sits within the confines of 
reality. We don't have perfect networks built. We don't have unlimited 
resources. We are facing a global pandemic. Money is tight. In 
principle, I agree with what you guys are saying. But in reality, 
we're going to have to bend our convictions in order to protect 
populations from COVID-19. You will be changing your tune when your 
mother is sick and can't get the care she needs because the system is 
overwhelmed because we (communities, not just network operators) 
didn't do what was necessary because of some idealistic hard line 
people drew in the sand.


- Mike Bolitho

Re: COVID-19 vs. our Networks

[Tom Beecher]

>
> You will be changing your tune when your mother is sick and can't get the
> care she needs because the system is overwhelmed because we (communities,
> not just network operators) didn't do what was necessary because of some
> idealistic hard line people drew in the sand.
>

The medical system is going to be run over by lack of trained professionals
/ beds / equipment long before it is unable to provide care because of
transient internet congestion.

I know you're under a lot of stress Mike, and I wish you all the best
getting through these current events.

On Fri, Mar 20, 2020 at 11:09 AM Mike Bolitho  wrote:

> "It is something that matters, because it has the potential to set a
>> dangerous precedent."
>>
>
> Can we stop with this talk... around everything? We're literally living
> through an unprecedented event right now. My 86 year old grandmother said
> she's never seen anything like this in the US. My friends 94 year old
> grandmother in Italy said she hasn't seen this since WWII. Nobody is going
> to say "Well we did this during a global pandemic so we can now do it
> because we feel like it". People will laugh them out of the room. I live in
> Phoenix, the mayor shut down bars and restaurants (carryout only) in order
> to help stop us from becoming Italy. One of our city councilmen was saying
> the same thing: "This is martial law and sets bad precedent! We must open
> everything up!" Of course, they then held a closed to the public meeting
> because city council can't be exposed. The point is, the mayor isn't going
> to do the same thing in six months on a whim because traffic on the freeway
> is bad. Thankfully calmer heads prevailed and the rest of the council told
> him to pound sand, at least for now.
>
> Something that keeps happening on this mailing list over the last few
> weeks is this tendency to try to take the "Moral high ground". And from way
> up there people are looking at the whole topic from an idealistic point of
> view like we live in some Network Operators Utopia with perfect conditions
> where money doesn't exist and we can do whatever we want because there is
> no upper management. We should be having a practical conversation that sits
> within the confines of reality. We don't have perfect networks built. We
> don't have unlimited resources. We are facing a global pandemic. Money is
> tight. In principle, I agree with what you guys are saying. But in reality,
> we're going to have to bend our convictions in order to protect populations
> from COVID-19. You will be changing your tune when your mother is sick and
> can't get the care she needs because the system is overwhelmed because we
> (communities, not just network operators) didn't do what was
> necessary because of some idealistic hard line people drew in the sand.
>
> - Mike Bolitho
>
>
> On Fri, Mar 20, 2020 at 7:44 AM Tom Beecher  wrote:
>
>> It is something that matters, because it has the potential to set a
>> dangerous precedent.
>>
>> If you say "$Service should reduce their bit rates because this is an
>> emergency!" , I guarantee that exact same argument will be made well after
>> this crisis has passed with a different definition of "emergency", and
>> adding on "well it's an emergency to me!".
>>
>> Some of the pipes Netflix goes through is also used by other services
>>> that aren't as adaptable.
>>>
>>
>> And how is that Netflix's responsibility? They have already taken action
>> to ramp down bitrates when they detect congestion. Why should other
>> applications be able to say piss off, I don't want to? Didn't we just have
>> a 10 year net neutrality argument that we're not supposed to want to treat
>> the bits differently?
>>
>> On Fri, Mar 20, 2020 at 10:17 AM Mike Hammett  wrote:
>>
>>> It's one of those most important things that matters.
>>>
>>> The end user likely won't notice the difference between 4k and 720p.
>>> They also aren't likely to notice the transition from one to the other.
>>>
>>> The person on the VPN, VoIP call, video conference, video game, etc.
>>> will very much notice the congested link, even if it's only a few seconds.
>>>
>>>
>>> Yes, Netflix video is very efficient, if not the most efficient. They're
>>> also one of if not the largest slingers of bits on the Internet. Small
>>> changes in usage of such a huge player totally eclipse most other usages on
>>> the Internet.
>>>
>>> https://help.netflix.com/en/node/306
>>>
>>> Netflix recommends 25 megs for Ultra HD, while only 5 megs for HD.
>>> That's a 5x difference in something people likely won't notice and would
>>> make a big difference on the additional VPN, VoIP, video conferencing, etc.
>>>
>>>
>>>
>>> -
>>> Mike Hammett
>>> Intelligent Computing Solutions 
>>> 
>>> 
>>> 
>>> 
>>> Midwest Internet Exchange 

RE: COVID-19 vs. our Networks

[Keith Medcalf]

On Friday, 20 March, 2020 07:52, Mike Hammett  wrote:

>Some of the pipes Netflix goes through is also used by other services
>that aren't as adaptable.

Can you explain why you think that is Netflix problem?

I should think that it is a problem being experienced by persons who 
deliberately chose to accept the risk that Internet congestion may be a problem 
for the path upon which they have deliberately chosen to embark.  That Risk 
might now come to fruition and those persons should be activating their 
pre-planned mitigation.  If their pre-planned mitigation was "well, Netflix can 
shut down", then they had (hopefully) defective mitigation planning.  Perhaps 
in the future they will do a better job of assessing Risk and mitigating that 
Risk.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

Re: COVID-19 vs. our Networks

[Mike Hammett]

I have neither the time, nor the inclination to do so for people that are not 
likely to be persuaded to change their position. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Keith Medcalf"  
To: "NANOG"  
Sent: Friday, March 20, 2020 10:35:57 AM 
Subject: RE: COVID-19 vs. our Networks 


On Friday, 20 March, 2020 07:52, Mike Hammett  wrote: 

>Some of the pipes Netflix goes through is also used by other services 
>that aren't as adaptable. 

Can you explain why you think that is Netflix problem? 

I should think that it is a problem being experienced by persons who 
deliberately chose to accept the risk that Internet congestion may be a problem 
for the path upon which they have deliberately chosen to embark. That Risk 
might now come to fruition and those persons should be activating their 
pre-planned mitigation. If their pre-planned mitigation was "well, Netflix can 
shut down", then they had (hopefully) defective mitigation planning. Perhaps in 
the future they will do a better job of assessing Risk and mitigating that 
Risk. 

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume. 

RE: COVID-19 vs. peering wars

[Adam Thompson]

Every large ISP does this (or rather, doesn't) at every IX in Canada.  Bell 
isn't unique by any stretch.

It's not in their economic interest to peer at a local IX, because from their 
perspective, the IX takes away business (Managed L2 point-to-point circuits, at 
the very least) from them.

Don't expect the dominant wireline ISP(s) in any region to join local IXes 
anytime soon, sadly, no matter how much it would benefit their customers.  
After all, the customer is always free to purchase service to the IX and join 
the IX, right???  *grumble*

In my local case, if BellMTS joined MBIX, un-cached DNS resolution times could 
potentially drop by 15msec.  That's HUGE.  But the end-user experience is not 
their primary goal.  Their primary goal is profit, as always.

-Adam Thompson
 Founding member, MBIX (once upon a time)

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

> -Original Message-
> From: NANOG  On Behalf Of Sadiq Saif
> Sent: Friday, March 20, 2020 9:38 AM
> To: nanog@nanog.org
> Subject: Re: COVID-19 vs. peering wars
> 
> On Fri, 20 Mar 2020, at 10:31, Steve Mikulasik via NANOG wrote:
> >
> > In Canada the CRTC really needs to get on Canadian ISPs about peering
> > very liberally at IXs in each province. I know of one major
> > institution right now that would have a major work from home issue
> > resolved if one big ISP would peer with one big tier 1 in the IX they
> > are both located at in the same province. Instead traffic needs to
> > flow across the country or to the USA to get back to the same city.
> 
> **cough** Bell Canada **cough**.
> 
> --
>   Sadiq Saif
>   https://sadiqsaif.com/

Re: COVID-19 vs. our Networks

[Rich Kulawiec]

On Fri, Mar 20, 2020 at 10:00:15AM -0500, Mike Hammett wrote:
> Because they're trying to be a responsible Internet citizen instead of just 
> telling everyone else to bugger off. 
> 
> 
> Perhaps if more entities tried to be responsible instead of entitled, the 
> Internet wouldn't be as bad as it is? 

+100.

In all the decades that I've been here (on the 'nets), the saddest change
I've seen is the lack of responsibility on the part of people who have,
by virtue of their positions, been given incredible power.  This is the
time for those people to step up and (try to) do the right thing.

None of us know what's going to be needed.  How could we?  We could guess,
and we *are* guessing, but we don't really know because we're sailing
off the edge of the map now.

In those circumstances, the virtue of frugality -- a sensible thing
at any time -- now becomes a necessity.  Every single one of us should
be doing whatever we can to prepare for the unknown, and conserving
resources is one part of that.

"Everything we do before a pandemic will seem alarmist.
Everything we do after will seem inadequate."
--- Michael Leavitt, former HHS Secretary

As I write this, doctors and nurses are working without PPE, risking
their own wellbeing to try to save patients.  We're not being asked
to do anything like that.  Hopefully we still have enough left to rise
to the comparatively minor challenge in front of us.

---rsk

Google and Coronavirus Tech Handbook

[Rob Pickering]

This: https://coronavirustechhandbook.com/home is a super useful resource
in my opinion.

They are using Google Docs because it provides a really accessible way of
doing content creation but hitting capacity issues.

Are there any Google contacts here who can get them talking to the right
people please?

Message me offlist and I will update here when sorted.

--
Rob Pickering, r...@pickering.org

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 21 Mar, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  801506
Prefixes after maximum aggregation (per Origin AS):  304658
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  391942
Total ASes present in the Internet Routing Table: 67449
Prefixes per ASN: 11.88
Origin-only ASes present in the Internet Routing Table:   57908
Origin ASes announcing only one prefix:   24286
Transit ASes present in the Internet Routing Table:9541
Transit-only ASes present in the Internet Routing Table:293
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  35
Max AS path prepend of ASN ( 27978)  31
Prefixes from unregistered ASNs in the Routing Table:  1206
Number of instances of unregistered ASNs:  1206
Number of 32-bit ASNs allocated by the RIRs:  31026
Number of 32-bit ASNs visible in the Routing Table:   25558
Prefixes from 32-bit ASNs in the Routing Table:  117712
Number of bogon 32-bit ASNs visible in the Routing Table:14
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:  0
Number of addresses announced to Internet:   2853027456
Equivalent to 170 /8s, 13 /16s and 190 /24s
Percentage of available address space announced:   77.1
Percentage of allocated address space announced:   77.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  594992

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   211614
Total APNIC prefixes after maximum aggregation:   61666
APNIC Deaggregation factor:3.43
Prefixes being announced from the APNIC address blocks:   0
Unique aggregates announced from the APNIC address blocks:0
APNIC Region origin ASes present in the Internet Routing Table:   10441
APNIC Prefixes per ASN:0.00
APNIC Region origin ASes announcing only one prefix:   2890
APNIC Region transit ASes present in the Internet Routing Table:   1554
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   5510
Number of APNIC addresses announced to Internet:  0
Equivalent to 0 /8s, 0 /16s and 0 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks  

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:234766
Total ARIN prefixes after maximum aggregation:   107906
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:0
Unique aggregates announced from the ARIN address blocks: 0
ARIN Region origin ASes present in the Internet Routing Table:18404
ARIN Prefixes per ASN: 0.00
ARIN Region origin ASes announcing only one prefix:6731
ARIN Region transit ASes present in the Internet Routing Table:1908
Average ARIN Region AS path length visible: 3.9
Max ARIN Region AS path length visible:  22
Number of ARIN region 32-bit ASNs visible in the Routing Table:3190
Number of ARIN addresses announced to Internet:   0
Equivalent to 0 /8s, 0 /16s and 0 /24s
ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048

Re: Google and Coronavirus Tech Handbook

[Alexandre Petrescu]

can I trust its CA?


Alex, LF/HF 2

Le 20/03/2020 à 18:54, Rob Pickering a écrit :
This: https://coronavirustechhandbook.com/home is a super useful 
resource in my opinion.


They are using Google Docs because it provides a really accessible way 
of doing content creation but hitting capacity issues.


Are there any Google contacts here who can get them talking to the 
right people please?


Message me offlist and I will update here when sorted.

--
Rob Pickering, r...@pickering.org 

Re: Google and Coronavirus Tech Handbook

[Rob Pickering]

CA?

On Fri, 20 Mar 2020 at 18:07, Alexandre Petrescu <
alexandre.petre...@gmail.com> wrote:

> can I trust its CA?
>
>
> Alex, LF/HF 2
>
> Le 20/03/2020 à 18:54, Rob Pickering a écrit :
>
> This: https://coronavirustechhandbook.com/home is a super useful resource
> in my opinion.
>
> They are using Google Docs because it provides a really accessible way of
> doing content creation but hitting capacity issues.
>
> Are there any Google contacts here who can get them talking to the right
> people please?
>
> Message me offlist and I will update here when sorted.
>
> --
> Rob Pickering, r...@pickering.org
>
>

-- 
--
Rob Pickering, r...@pickering.org

Re: Google and Coronavirus Tech Handbook

[Alexandre Petrescu]

CA==Certificate Authority

the browser makes me questions before allowing me to see the content, 
after I click the indicated URL


LF/HF

Le 20/03/2020 à 19:08, Rob Pickering a écrit :

CA?

On Fri, 20 Mar 2020 at 18:07, Alexandre Petrescu 
mailto:alexandre.petre...@gmail.com>> 
wrote:


can I trust its CA?


Alex, LF/HF 2

Le 20/03/2020 à 18:54, Rob Pickering a écrit :

This: https://coronavirustechhandbook.com/home is a super useful
resource in my opinion.

They are using Google Docs because it provides a really
accessible way of doing content creation but hitting capacity issues.

Are there any Google contacts here who can get them talking to
the right people please?

Message me offlist and I will update here when sorted.

--
Rob Pickering, r...@pickering.org 




--
--
Rob Pickering, r...@pickering.org 

Re: Google and Coronavirus Tech Handbook

[Rob Pickering]

On Fri, 20 Mar 2020 at 18:11, Alexandre Petrescu <
alexandre.petre...@gmail.com> wrote:

> CA==Certificate Authority
>
> the browser makes me questions before allowing me to see the content,
> after I click the indicated URL
>
> LF/HF
>
> What root CA list are you using?

I'm not at all involved in their hosting, but it looks like they are
sitting behind Cloudflare SSL which is trusted by the default CA list of
the browser vendor on my desktop.

--
Rob Pickering, r...@pickering.org

Re: Google and Coronavirus Tech Handbook

[Alexandre Petrescu]

You are asking what root CA list I am using?

I answer: I use firefox browser on Windows 10 latest version.  I dont 
know what root CA I use.  I have several root CAs in my browser's 
option.  Most of them came by default in firefow at install time.  A few 
I had to install  manually many months ago, because I had a one-to-one 
trust developped with a few people and their CAs.


About cloudflare I think the followiing: I have seen it used at IETF 
servers.  It takes a few seconds to check, which is fine. But I dont 
understand why its getting in the way.  They should stop getting in 
people's way to browse for information.


Now, I do not understand why my browser, that I consider clean, makes me 
questions about security, certificates, and so on.  It might be that the 
right CA is not inserted in my CA list, I dont know, I have not looked 
in the firefox options today.  But it is strange I could browse IETF ok 
with cloudflare, no question from the browser, but now there are 
questions in the browser about cloudflare and the URL you point to.


Yours,

I sign: Alex, LF/HF 2 (it means low stress)

Le 20/03/2020 à 19:40, Rob Pickering a écrit :



On Fri, 20 Mar 2020 at 18:11, Alexandre Petrescu 
mailto:alexandre.petre...@gmail.com>> 
wrote:


CA==Certificate Authority

the browser makes me questions before allowing me to see the
content, after I click the indicated URL

LF/HF

What root CA list are you using?

I'm not at all involved in their hosting, but it looks like they are 
sitting behind Cloudflare SSL which is trusted by the default CA list 
of the browser vendor on my desktop.


--
Rob Pickering, r...@pickering.org 

Re: Google and Coronavirus Tech Handbook

[Alexandre Petrescu]

What is your browser vendor on your desktop?

Alex, LF/HF 2

Le 20/03/2020 à 19:40, Rob Pickering a écrit :



On Fri, 20 Mar 2020 at 18:11, Alexandre Petrescu 
mailto:alexandre.petre...@gmail.com>> 
wrote:


CA==Certificate Authority

the browser makes me questions before allowing me to see the
content, after I click the indicated URL

LF/HF

What root CA list are you using?

I'm not at all involved in their hosting, but it looks like they are 
sitting behind Cloudflare SSL which is trusted by the default CA list 
of the browser vendor on my desktop.


--
Rob Pickering, r...@pickering.org 

Re: COVID-19 vs. peering wars

[Matthew Petach]

I'm curious;
would people say that fixing peering inefficiencies could have
a bigger impact on service performance than asking that
Netflix, Amazon Prime, Youtube, Hulu, and other video
streaming services cut their bit rates down?

https://www.bbc.com/news/technology-51968302
https://arstechnica.com/tech-policy/2020/03/netflix-and-youtube-cut-streaming-quality-in-europe-to-handle-pandemic/

It seems that perhaps the fingers, and the regulatory
hammer, are being pointed in the wrong direction at
the moment.  ^_^;

Matt
staying safely under the saran-wrap blanket for the next few weeks




On Fri, Mar 20, 2020 at 9:31 AM Adam Thompson 
wrote:

> Every large ISP does this (or rather, doesn't) at every IX in Canada.
> Bell isn't unique by any stretch.
>
> It's not in their economic interest to peer at a local IX, because from
> their perspective, the IX takes away business (Managed L2 point-to-point
> circuits, at the very least) from them.
>
> Don't expect the dominant wireline ISP(s) in any region to join local IXes
> anytime soon, sadly, no matter how much it would benefit their customers.
> After all, the customer is always free to purchase service to the IX and
> join the IX, right???  *grumble*
>
> In my local case, if BellMTS joined MBIX, un-cached DNS resolution times
> could potentially drop by 15msec.  That's HUGE.  But the end-user
> experience is not their primary goal.  Their primary goal is profit, as
> always.
>
> -Adam Thompson
>  Founding member, MBIX (once upon a time)
>
> Adam Thompson
> Consultant, Infrastructure Services
> MERLIN
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
>
> > -Original Message-
> > From: NANOG  On Behalf Of Sadiq Saif
> > Sent: Friday, March 20, 2020 9:38 AM
> > To: nanog@nanog.org
> > Subject: Re: COVID-19 vs. peering wars
> >
> > On Fri, 20 Mar 2020, at 10:31, Steve Mikulasik via NANOG wrote:
> > >
> > > In Canada the CRTC really needs to get on Canadian ISPs about peering
> > > very liberally at IXs in each province. I know of one major
> > > institution right now that would have a major work from home issue
> > > resolved if one big ISP would peer with one big tier 1 in the IX they
> > > are both located at in the same province. Instead traffic needs to
> > > flow across the country or to the USA to get back to the same city.
> >
> > **cough** Bell Canada **cough**.
> >
> > --
> >   Sadiq Saif
> >   https://sadiqsaif.com/
>
>

Re: Google and Coronavirus Tech Handbook

[Alexandre Petrescu]

Rob,

You told me in private a few moments ago that if I cant help with fixin 
an AS-number issue critical to you, then I should drop from this thread.


I think I will drop out from this email list altogether.  I wait a bit.

Alex LF/HF 2

Le 20/03/2020 à 19:40, Rob Pickering a écrit :



On Fri, 20 Mar 2020 at 18:11, Alexandre Petrescu 
mailto:alexandre.petre...@gmail.com>> 
wrote:


CA==Certificate Authority

the browser makes me questions before allowing me to see the
content, after I click the indicated URL

LF/HF

What root CA list are you using?

I'm not at all involved in their hosting, but it looks like they are 
sitting behind Cloudflare SSL which is trusted by the default CA list 
of the browser vendor on my desktop.


--
Rob Pickering, r...@pickering.org 

Re: Google and Coronavirus Tech Handbook

[Alexandre Petrescu]

please stop writing me private emails, thank you, with due politeness 
and smiley :-)



Alex, LF/HF 2

Le 20/03/2020 à 19:40, Rob Pickering a écrit :



On Fri, 20 Mar 2020 at 18:11, Alexandre Petrescu 
mailto:alexandre.petre...@gmail.com>> 
wrote:


CA==Certificate Authority

the browser makes me questions before allowing me to see the
content, after I click the indicated URL

LF/HF

What root CA list are you using?

I'm not at all involved in their hosting, but it looks like they are 
sitting behind Cloudflare SSL which is trusted by the default CA list 
of the browser vendor on my desktop.


--
Rob Pickering, r...@pickering.org 

Re: Google and Coronavirus Tech Handbook

[Rob Pickering]

On Fri, 20 Mar 2020, 20:08 Alexandre Petrescu, 
wrote:

> Rob,
>
> You told me in private a few moments ago that if I cant help with fixin an
> AS-number issue critical to you, then I should drop from this thread.
>

I actually said "help reaching someone from AS15169" but, apart from that,
yes good paraphrase.

Please don't be offended, I'm just trying to help what I think is a super
important resource stay accessible by connecting them to someone at Google
who can help with a Google Docs access capacity issue they are having.
Conversations about root CAs are noise in that context.

Thank you.

Re: Google and Coronavirus Tech Handbook

[Eric Tykwinski]

Alex, Rob,

So I advised to run through Qualsys’s SSL Test: 
https://www.ssllabs.com/ssltest/analyze.html?d=coronavirustechhandbook.com 

It’s pretty much fine, I did manually run though LibreSSL 2.6.5 with OSX 
10.14.6 and it errors out, but that’s usually an edge case.

eric$ openssl s_client -connect coronavirustechhandbook.com:443 -showcerts 
-tls1_2 -crlf
CONNECTED(0006)
4526024300:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert 
handshake 
failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:1205:SSL
 alert number 40
4526024300:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake 
failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:585:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: 
Session-ID: 
Session-ID-ctx: 
Master-Key: 
Start Time: 1584736646
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

> On Mar 20, 2020, at 4:34 PM, Alexandre Petrescu 
>  wrote:
> 
> please stop writing me private emails, thank you, with due politeness and 
> smiley :-)
> 
> 
> 
> Alex, LF/HF 2
> Le 20/03/2020 à 19:40, Rob Pickering a écrit :
>> 
>> 
>> On Fri, 20 Mar 2020 at 18:11, Alexandre Petrescu 
>> mailto:alexandre.petre...@gmail.com>> wrote:
>> CA==Certificate Authority
>> 
>> the browser makes me questions before allowing me to see the content, after 
>> I click the indicated URL
>> 
>> LF/HF
>> What root CA list are you using?
>> 
>> I'm not at all involved in their hosting, but it looks like they are sitting 
>> behind Cloudflare SSL which is trusted by the default CA list of the browser 
>> vendor on my desktop.
>> 
>> --
>> Rob Pickering, r...@pickering.org 

Re: Google and Coronavirus Tech Handbook

[Randy Bush]

it has "Places Tracking the Data" but needs "Places Tracking You"

considering the javascript i had to enable in the scratch vm i spun up
to read it, i suspect this would be on that list.

randy

Re: Google and Coronavirus Tech Handbook

[Alexandre Petrescu]

Thank you very much for the confirmation.

I will now access the http about the handbook and accept the exception 
in my browser.


There is no offence and I thank you for your understanding.

Yours,

Alex, LF/HF 2

Le 20/03/2020 à 21:40, Eric Tykwinski a écrit :

Alex, Rob,

So I advised to run through Qualsys’s SSL Test: 
https://www.ssllabs.com/ssltest/analyze.html?d=coronavirustechhandbook.com
It’s pretty much fine, I did manually run though LibreSSL 2.6.5 with 
OSX 10.14.6 and it errors out, but that’s usually an edge case.


eric$ openssl s_client -connect coronavirustechhandbook.com:443 
 -showcerts -tls1_2 -crlf

CONNECTED(0006)
4526024300:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 
alert handshake 
failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:1205:SSL 
alert number 40
4526024300:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl 
handshake 
failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:585:

---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
  Protocol  : TLSv1.2
  Cipher    : 
  Session-ID:
  Session-ID-ctx:
  Master-Key:
  Start Time: 1584736646
  Timeout   : 7200 (sec)
  Verify return code: 0 (ok)
---

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

On Mar 20, 2020, at 4:34 PM, Alexandre Petrescu 
mailto:alexandre.petre...@gmail.com>> 
wrote:


please stop writing me private emails, thank you, with due politeness 
and smiley :-)



Alex, LF/HF 2
Le 20/03/2020 à 19:40, Rob Pickering a écrit :



On Fri, 20 Mar 2020 at 18:11, Alexandre Petrescu 
mailto:alexandre.petre...@gmail.com>> 
wrote:


CA==Certificate Authority

the browser makes me questions before allowing me to see the
content, after I click the indicated URL

LF/HF

What root CA list are you using?

I'm not at all involved in their hosting, but it looks like they are 
sitting behind Cloudflare SSL which is trusted by the default CA 
list of the browser vendor on my desktop.


--
Rob Pickering, r...@pickering.org 

Re: Google and Coronavirus Tech Handbook

[Alexandre Petrescu]

After trying to access it, I hit my company http gateway (I am on a VPN 
for my default route, company policy) who blocks it.


I will get off the VPN to try to access the Coronavirus Tech Handbook on 
the Internet.


Alex, LF/HF 2

Le 20/03/2020 à 22:04, Alexandre Petrescu a écrit :


Thank you very much for the confirmation.

I will now access the http about the handbook and accept the exception 
in my browser.


There is no offence and I thank you for your understanding.

Yours,

Alex, LF/HF 2
Le 20/03/2020 à 21:40, Eric Tykwinski a écrit :

Alex, Rob,

So I advised to run through Qualsys’s SSL Test: 
https://www.ssllabs.com/ssltest/analyze.html?d=coronavirustechhandbook.com
It’s pretty much fine, I did manually run though LibreSSL 2.6.5 with 
OSX 10.14.6 and it errors out, but that’s usually an edge case.


eric$ openssl s_client -connect coronavirustechhandbook.com:443 
 -showcerts -tls1_2 -crlf

CONNECTED(0006)
4526024300:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 
alert handshake 
failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:1205:SSL 
alert number 40
4526024300:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl 
handshake 
failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:585:

---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Start Time: 1584736646
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

On Mar 20, 2020, at 4:34 PM, Alexandre Petrescu 
mailto:alexandre.petre...@gmail.com>> 
wrote:


please stop writing me private emails, thank you, with due 
politeness and smiley :-)



Alex, LF/HF 2
Le 20/03/2020 à 19:40, Rob Pickering a écrit :



On Fri, 20 Mar 2020 at 18:11, Alexandre Petrescu 
> wrote:


CA==Certificate Authority

the browser makes me questions before allowing me to see the
content, after I click the indicated URL

LF/HF

What root CA list are you using?

I'm not at all involved in their hosting, but it looks like they 
are sitting behind Cloudflare SSL which is trusted by the default 
CA list of the browser vendor on my desktop.


--
Rob Pickering, r...@pickering.org 

Re: Google and Coronavirus Tech Handbook

[Alexandre Petrescu]

1. I did not understand why you call it "_Google_ and... Handbook"

Is Google part of this? I dont see it in the pages.

2. Now I realize it works ok to browse 
https://coronavirustechhandbook.com/home


but only if I am not on mandatory organisation VPN (my employer).

3. That handbook shows sole facebook group to subscribe to, a twitter, a 
chat opportunity.


There is also a "Isolation Toolkit Tips for staying at home, doing 
physical distancing correctly, and managing your mental health." among 
others.


There are directories of volunteering groups, which I think it is a 
great idea.


The presentation reminds of Altavista and Yahoo directories when I 
imagined I could browse all the Internet through it.  It's strange 
Google does the same now, instead of searching :-)


Also, about the presentation, they use a particular logo, round shape, 
three black circles like they were 'claws' on yellow background.  I 
think that's hazardous logo for chemistry material: when I see that 
typically I stay away from such logos, it spells danger. I dont knnow 
why they put that there.


Finally, if this handbook is something that comes from UK (because they 
say "If you are not a specialist: www.gov.uk/coronavirus (or your 
regional equivalent)") then my advice is the following: UK recently went 
through a denial period; during that denial period they made wrong 
advices (remember: travel from US to UK only, not to EU); I hope they 
changed their advice and very fast.  Otherwise, UK is not trustful for 
me at this time.  No offence to anyone from UK (I have trustful friends 
in UK), and with all due respect.


Yours,

Alex, LF/HF 2

Le 20/03/2020 à 22:06, Alexandre Petrescu a écrit :


After trying to access it, I hit my company http gateway (I am on a 
VPN for my default route, company policy) who blocks it.


I will get off the VPN to try to access the Coronavirus Tech Handbook 
on the Internet.


Alex, LF/HF 2
Le 20/03/2020 à 22:04, Alexandre Petrescu a écrit :


Thank you very much for the confirmation.

I will now access the http about the handbook and accept the 
exception in my browser.


There is no offence and I thank you for your understanding.

Yours,

Alex, LF/HF 2
Le 20/03/2020 à 21:40, Eric Tykwinski a écrit :

Alex, Rob,

So I advised to run through Qualsys’s SSL Test: 
https://www.ssllabs.com/ssltest/analyze.html?d=coronavirustechhandbook.com
It’s pretty much fine, I did manually run though LibreSSL 2.6.5 with 
OSX 10.14.6 and it errors out, but that’s usually an edge case.


eric$ openssl s_client -connect coronavirustechhandbook.com:443 
 -showcerts -tls1_2 -crlf

CONNECTED(0006)
4526024300:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 
alert handshake 
failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:1205:SSL 
alert number 40
4526024300:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl 
handshake 
failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:585:

---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Start Time: 1584736646
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

On Mar 20, 2020, at 4:34 PM, Alexandre Petrescu 
> wrote:


please stop writing me private emails, thank you, with due 
politeness and smiley :-)



Alex, LF/HF 2
Le 20/03/2020 à 19:40, Rob Pickering a écrit :



On Fri, 20 Mar 2020 at 18:11, Alexandre Petrescu 
> wrote:


CA==Certificate Authority

the browser makes me questions before allowing me to see the
content, after I click the indicated URL

LF/HF

What root CA list are you using?

I'm not at all involved in their hosting, but it looks like they 
are sitting behind Cloudflare SSL which is trusted by the default 
CA list of the browser vendor on my desktop.


--
Rob Pickering, r...@pickering.org 

interesting troubleshooting

[Nimrod Levy]

I just ran into an issue that I thought was worth sharing with the NANOG
community. With recently increased visibility on keeping the Internet
running smoothly, I thought that sharing this small experience could
benefit everyone.

I was contacted by my NOC to investigate a LAG that was not distributing
traffic evenly among the members to the point where one member was
congested while the utilization on the LAG was reasonably low. Looking at
my netflow data, I was able to confirm that this was caused by a single
large flow of ESP traffic. Fortunately, I was able to shift this flow to
another path that had enough headroom available so that the flow could be
accommodated on a single member link.

With the increase in remote workers and VPN traffic that won't hash across
multiple paths, I thought this anecdote might help someone else track down
a problem that might not be so obvious.

Please take this message in the spirit in which it was intended and refrain
from the snarky "just upgrade you links" comments.

-- 
Nimrod

Re: Google and Coronavirus Tech Handbook

[Rob Pickering]

On Fri, 20 Mar 2020 at 21:20, Alexandre Petrescu <
alexandre.petre...@gmail.com> wrote:

> 1. I did not understand why you call it "_Google_ and... Handbook"
>

For goodness sake I posted here looking for an AS15169 contact for a useful
project that needs some of their help.

What I seem to be getting is a bunch of critique from folks who
don't understand the difference between the Internet and a corporate VPN
which is MITMing their SSL traffic about the merits of the technology
choices the project made and the country it originates in (in case you
haven't noticed all of our governments are all screwing this up).

Nanog has gone to the dogs, it wasn't like this after 9/11!

Thanks folks.

Re: interesting troubleshooting

[Job Snijders]

On Fri, Mar 20, 2020 at 05:33:31PM -0400, Nimrod Levy wrote:
> With the increase in remote workers and VPN traffic that won't hash across
> multiple paths, I thought this anecdote might help someone else track down
> a problem that might not be so obvious.

Do we know which specific VPN technologies specifically are harder to
hash in a meaningful way for load balanacing purposes, than others?

If the outcome of this troubleshooting is a list of recommendations
about which VPN approaches to use, and which ones to avoid (because of
the issue you described), that'll be a great outcome.

Kind regards,

Job

Re: interesting troubleshooting

[Jared Mauch]

> On Mar 20, 2020, at 5:50 PM, Job Snijders  wrote:
> 
> On Fri, Mar 20, 2020 at 05:33:31PM -0400, Nimrod Levy wrote:
>> With the increase in remote workers and VPN traffic that won't hash across
>> multiple paths, I thought this anecdote might help someone else track down
>> a problem that might not be so obvious.
> 
> Do we know which specific VPN technologies specifically are harder to
> hash in a meaningful way for load balanacing purposes, than others?
> 
> If the outcome of this troubleshooting is a list of recommendations
> about which VPN approaches to use, and which ones to avoid (because of
> the issue you described), that'll be a great outcome.
> 

It’s the protocol 50 IPSEC VPNs.  They are very sensitive to path changes and 
reordering as well.

If you’re tunneling more than 5 or 10Gb/s of IPSEC it’s likely going to be a 
bad day when you find a low speed link in the middle.  Generally providers with 
these types of flows have both sides on the same network vs going off-net as 
they’re not stable on peering links that might change paths.

You also need to watch out to ensure you’re not on some L2VPN type product that 
bumps up against a barrier.  I know it’s a stressful time for many networks and 
systems people as traffic shifts.  Good luck out there!

- Jared

Re: Google and Coronavirus Tech Handbook

[Alexandre Petrescu]

Rob,

It is all fine.

I did not want to say anything to enter part of a bunch of critique, sorry.

I value the pointer to document.

Being on VPN means to some times get useful info that others dont have, 
and other times it means to be denied useful info that others have.  But 
VPN is mandatory policy in some places.  It has nothing to do with Nanog 
policy, if there is one.  There might be a need to link together the VPN 
world with the non-VPN world.


Nanog is a great place where people keep the Internet running by 
collaboration, including AS numbers.


Yours,

Alex, LF/HF 2

Le 20/03/2020 à 22:47, Rob Pickering a écrit :



On Fri, 20 Mar 2020 at 21:20, Alexandre Petrescu 
mailto:alexandre.petre...@gmail.com>> 
wrote:


1. I did not understand why you call it "_Google_ and... Handbook"


For goodness sake I posted here looking for an AS15169 contact for a 
useful project that needs some of their help.


What I seem to be getting is a bunch of critique from folks who 
don't understand the difference between the Internet and a corporate 
VPN which is MITMing their SSL traffic about the merits of the 
technology choices the project made and the country it originates in 
(in case you haven't noticed all of our governments are all screwing 
this up).


Nanog has gone to the dogs, it wasn't like this after 9/11!

Thanks folks.

Re: interesting troubleshooting

[Saku Ytti]

Hey Nimrod,

> I was contacted by my NOC to investigate a LAG that was not distributing 
> traffic evenly among the members to the point where one member was congested 
> while the utilization on the LAG was reasonably low. Looking at my netflow 
> data, I was able to confirm that this was caused by a single large flow of 
> ESP traffic. Fortunately, I was able to shift this flow to another path that 
> had enough headroom available so that the flow could be accommodated on a 
> single member link.
>
> With the increase in remote workers and VPN traffic that won't hash across 
> multiple paths, I thought this anecdote might help someone else track down a 
> problem that might not be so obvious.

This problem is called elephant flow. Some vendors have solution for
this, by dynamically monitoring utilisation and remapping the
hashResult => egressInt table to create bias to offset the elephant
flow.

One particular example:
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/adaptive-edit-interfaces-aex-aggregated-ether-options-load-balance.html

Ideally VPN providers would be defensive and would use SPORT for
entropy, like MPLSoUDP does.

-- 
  ++ytti

It's not about the congestion, it's about the profit motive driving the industry

[Matthew Petach]

On Tue, Mar 17, 2020 at 10:52 AM Mike Bolitho  wrote:

> >You're facing essentially the same issue as many in non-healthcare do ;
> how to best talk to applications in Magic Cloud Land. Reaching the major
> cloud providers does not require DIA ; they all have presences on the major
> IXes, and direct peering could be an option too depending on your needs and
> traffic.
>
> I totally agree and 99.999% of the time, congestion on the Internet is a
> nuisance, not a critical problem. I'm not sitting here complaining that my
> public internet circuits don't have SLAs or that we run into some packet
> loss and latency here and there under normal operations. That's obviously
> to be expected. But this whole topic is around what to do when a once in a
> lifetime pandemic hits and we're faced with unseen levels of congestion
> across the country's infrastructure. I mean the thread is titled COVID-19
> Vs Our Networks. That's why I brought up the possible application of TSP to
> tell some of the big CDNs that maybe they should limit 4K streaming or big
> DLCs during a pandemic. That's it. And yet I'm getting chastised (not
> necessarily by you) for suggesting that hospitals, governments, water
> treatment plants, power plants, first responders, etc are actually more
> important during times like this.
>
> - Mike Bolitho
>

I think it's time to re-stock on the "The Cloud Is Just Someone Else's
Computer In A Different Building" stickers...

While having streaming services voluntarily ratchet
their bitrates down during the crisis is a nice enough
response, I think the deeper underlying issue is that
any system that is CRITICAL for maintaining health and
safety during a pandemic or other crisis MUST be
capable of operating standalone in case the rest of
the infrastructure has melted down.

X-Ray systems at hospitals that refuse to work when
they can't talk to a license server in the cloud?

Nope.

If there's government intervention and regulation
that comes out of this, it should focus not on TSP
responses during a crisis, but on ensuring that
manufacturers of healthcare devices do not prioritize
making money over saving lives.

IF there is regulation to be made after this, THAT is what
it needs to focus on.

Internet congestion is a symptom, not the cause of this
thread.  Fix the real problem.
CRITICAL health care systems must be capable of operating
on their own during a state of emergency, not held captive to
the profit motives of rich executives.  :/

Matt
who finds it appalling that we consider it more important to make
money than to save lives.  :(


>
>
> On Tue, Mar 17, 2020 at 10:35 AM Tom Beecher  wrote:
>
>> You're facing essentially the same issue as many in non-healthcare do ;
>> how to best talk to applications in Magic Cloud Land. Reaching the major
>> cloud providers does not require DIA ; they all have presences on the major
>> IXes, and direct peering could be an option too depending on your needs and
>> traffic.
>>
>> I don't mean to be dismissive of the issues you face, I apologize if
>> that's how it comes off. What you describe is certainly challenging, but I
>> think that you will have better success with some of the options that are
>> out there already than hoping for any resolution of intermittent congestion
>> issues in the wild west of the DFZ.
>>
>

Re: interesting troubleshooting

[Chris Adams]

Once upon a time, Nimrod Levy  said:
> With the increase in remote workers and VPN traffic that won't hash across
> multiple paths, I thought this anecdote might help someone else track down
> a problem that might not be so obvious.

Last week I ran into an issue where traffic between my home and work
networks had high latency, but only to certain IPs (even different IPs
on the same server).  Since my work network peers with my home provider,
I was able to go to the provider's NOC, and they were very helpful (they
ended up turning up more bandwidth).  I expect this was also a case of
one LAG member being congested, and my problem IP pairs were hashing to
that member.

My traffic wasn't VPN (SSH, with ping/mtr for testing), but it is
possible that somebody else's was - I didn't get detailed with the other
NOC.
-- 
Chris Adams 

Re: interesting troubleshooting

[Matthew Petach]

On Fri, Mar 20, 2020 at 3:09 PM Saku Ytti  wrote:

> Hey Nimrod,
>
> > I was contacted by my NOC to investigate a LAG that was not distributing
> traffic evenly among the members to the point where one member was
> congested while the utilization on the LAG was reasonably low. Looking at
> my netflow data, I was able to confirm that this was caused by a single
> large flow of ESP traffic. Fortunately, I was able to shift this flow to
> another path that had enough headroom available so that the flow could be
> accommodated on a single member link.
> >
> > With the increase in remote workers and VPN traffic that won't hash
> across multiple paths, I thought this anecdote might help someone else
> track down a problem that might not be so obvious.
>
> This problem is called elephant flow. Some vendors have solution for
> this, by dynamically monitoring utilisation and remapping the
> hashResult => egressInt table to create bias to offset the elephant
> flow.
>
> One particular example:
>
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/adaptive-edit-interfaces-aex-aggregated-ether-options-load-balance.html
>
> Ideally VPN providers would be defensive and would use SPORT for
> entropy, like MPLSoUDP does.
>
> --
>   ++ytti
>
>

There are *several* caveats to doing dynamic monitoring and remapping of
flows; one of the biggest challenges is that it puts extra demands on the
line cards tracking the flows, especially as the number of flows rises to
large values.  I recommend reading
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/load-balancing-aggregated-ethernet-interfaces.html#id-understanding-aggregated-ethernet-load-balancing
before configuring it.

"Although the feature performance is high, it consumes significant amount
of line card memory. Approximately, 4000 logical interfaces or 16
aggregated Ethernet logical interfaces can have this feature enabled on
supported MPCs. However, when the Packet Forwarding Engine hardware memory
is low, depending upon the available memory, it falls back to the default
load balancing mechanism."

What is that old saying?

Oh, right--There Ain't No Such Thing As A Free Lunch.   ^_^;;

Matt

Re: interesting troubleshooting

[Job Snijders]

On Fri, Mar 20, 2020 at 05:57:19PM -0400, Jared Mauch wrote:
> You also need to watch out to ensure you’re not on some L2VPN type
> product that bumps up against a barrier.  I know it’s a stressful time
> for many networks and systems people as traffic shifts. 

A few years ago we did a presentation about what can happen if hashing
for load balancing purposes doesn't work well (be it either IP or L2VPN
traffic). I think some of the information is still relevant as there
really isn't much difference between the problem existing in the
underlay network's implementation of algorithms or the properties of the
enveloppe that encompasses the overlay network packet.

video of younger job + jeff: https://www.youtube.com/watch?v=cXSwoKu9zOg
slides: 
https://archive.nanog.org/meetings/nanog57/presentations/Tuesday/tues.general.SnijdersWheeler.MACaddresses.14.pdf

Kind regards,

Job

Re: interesting troubleshooting

[Steve Meuse]

What that large flow in a single LSP? Is this something that FAT lsp would
fix?

-Steve


On Fri, Mar 20, 2020 at 5:33 PM Nimrod Levy  wrote:

> I just ran into an issue that I thought was worth sharing with the NANOG
> community. With recently increased visibility on keeping the Internet
> running smoothly, I thought that sharing this small experience could
> benefit everyone.
>
> I was contacted by my NOC to investigate a LAG that was not distributing
> traffic evenly among the members to the point where one member was
> congested while the utilization on the LAG was reasonably low. Looking at
> my netflow data, I was able to confirm that this was caused by a single
> large flow of ESP traffic. Fortunately, I was able to shift this flow to
> another path that had enough headroom available so that the flow could be
> accommodated on a single member link.
>
> With the increase in remote workers and VPN traffic that won't hash across
> multiple paths, I thought this anecdote might help someone else track down
> a problem that might not be so obvious.
>
> Please take this message in the spirit in which it was intended and
> refrain from the snarky "just upgrade you links" comments.
>
> --
> Nimrod
>

Re: COVID-19 vs. our Networks

[Mark Tinka]

On 20/Mar/20 15:32, Blake Hudson wrote:

>
>
> Across several eyeball networks I'm not seeing any noticeable increase
> in peak (95%) demand between now and January. Since Netflix
> automatically scales down data rates in the event of congestion, the
> only thing I foresee forcing Netflix to reduce data rates [ahead of
> any congestion] would accomplish is causing excess link capacity to go
> unused (wasted). This sounds like a policy decision made without a
> technical argument... e.g. not a data driven decision, but a decision
> made out of fear or panic.

Yep - the command & control culture.

Mark.

Re: COVID-19 vs. our Networks

[Mark Tinka]

On 20/Mar/20 15:51, Mike Hammett wrote:
> Why in the world would they do that?
>
> Maybe waive the fees for the higher services, but you're not entitled
> to anything more than that.

Users will pay for value.

If users don't see value, they will respond accordingly.

Mark.

Re: COVID-19 vs. our Networks

[Mark Tinka]

On 20/Mar/20 15:52, Mike Hammett wrote:
> Some of the pipes Netflix goes through is also used by other services
> that aren't as adaptable.

I think that's case specific on the type of network you have built, and
whether your feed your customers Netflix content with on on-site OCA or
via an exchange point or transit link.

Mark.

Re: CISA: Guidance on the Essential Critical Infrastructure Workforce

[Mark Tinka]

On 20/Mar/20 15:53, Alexandre Petrescu wrote:

>
> In France I must show a paper (not smartphone) printed permit, each
> sortie one different paper.  The receiver of it (police) takes it in
> his/her gloved hands then s/he passes it back to me.  I do not have
> gloves.  I wished the receiver did not use the same gloves for each
> pereson who passes by and delivers that paper to him.
>

Yep, couldn't believe it when my mate in Lyon told me the same thing
this week.

But I suppose this was to be expected, and is an idea that could
potentially spread, worldwide.

Mark.

Re: COVID-19 vs. our Networks

[Mark Tinka]

On 20/Mar/20 16:15, Mike Hammett wrote:
> It's one of those most important things that matters.
>
> The end user likely won't notice the difference between 4k and 720p.
> They also aren't likely to notice the transition from one to the other.
>
> The person on the VPN, VoIP call, video conference, video game, etc.
> will very much notice the congested link, even if it's only a few seconds.
>
>
> Yes, Netflix video is very efficient, if not the most efficient.
> They're also one of if not the largest slingers of bits on the
> Internet. Small changes in usage of such a huge player totally eclipse
> most other usages on the Internet.
>
> https://help.netflix.com/en/node/306
>
> Netflix recommends 25 megs for Ultra HD, while only 5 megs for HD.
> That's a 5x difference in something people likely won't notice and
> would make a big difference on the additional VPN, VoIP, video
> conferencing, etc.

Considering that the telecoms sector is one of the most traveled group
of professional people around the world, on a 12-month basis, that would
mean all the meetings we hold, each week, somewhere in the world,
racking up air miles galore, was a total waste of time if it's all
reduced to this.

Don't let your Finance departments read this thread - they'll just cut
your travel budgets :-).

Mark.

Re: COVID-19 vs. our Networks

[Mark Tinka]

On 20/Mar/20 17:00, Mike Hammett wrote:

>
> Perhaps if more entities tried to be responsible instead of entitled,
> the Internet wouldn't be as bad as it is?

I half agree with your last sentence.

More entities don't need to be entitled (which I don't think Netflix
are, to be clear), but they need to listen to customers and offer them
value (not product).

Customers have never been more in the driver's seat in this new economy
than ever before. They will quickly show you how irrelevant you are to them.

Whatever move(s) Netflix or the command & control policy people make
here, customers will respond accordingly.

Mark.

Re: COVID-19 vs. our Networks

[Mark Tinka]

On 20/Mar/20 19:38, Rich Kulawiec wrote:

> +100.
>
> In all the decades that I've been here (on the 'nets), the saddest change
> I've seen is the lack of responsibility on the part of people who have,
> by virtue of their positions, been given incredible power.  This is the
> time for those people to step up and (try to) do the right thing.
>
> None of us know what's going to be needed.  How could we?  We could guess,
> and we *are* guessing, but we don't really know because we're sailing
> off the edge of the map now.
>
> In those circumstances, the virtue of frugality -- a sensible thing
> at any time -- now becomes a necessity.  Every single one of us should
> be doing whatever we can to prepare for the unknown, and conserving
> resources is one part of that.
>
>   "Everything we do before a pandemic will seem alarmist.
>   Everything we do after will seem inadequate."
>   --- Michael Leavitt, former HHS Secretary
>
> As I write this, doctors and nurses are working without PPE, risking
> their own wellbeing to try to save patients.  We're not being asked
> to do anything like that.  Hopefully we still have enough left to rise
> to the comparatively minor challenge in front of us.

All I'm saying is at the moment, there is no empirical information to
suggest that Netflix will break what's left of the Internet. Nor is
there any empirical information suggesting that singling them out will
help keep it going.

If we go down this path, who's to say which service provider will or
won't be "targeted" next at the whim of some command & control policy
maker? Is it a rabbit hole whose top-soil we want to uncover?
 
If/when the network starts to take a hit, network operators will
respond. But if there is any operator on this list who is willing to
raise their hands and say, "Netflix is breaking my network",
uncongested, free-flowing beer on me when we all come out from the bunkers.

Mark.

Re: interesting troubleshooting

[William Herrin]

On Fri, Mar 20, 2020 at 3:07 PM Job Snijders  wrote:
> Do we know which specific VPN technologies specifically are harder to
> hash in a meaningful way for load balanacing purposes, than others?

I would expect it to be true of any site to site VPN data flow. The
whole idea is for the guy in the middle to be unable to deduce
anything about the flow. If the technology provides hints about which
packets match the same subflow, it isn't doing a very good job.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

RE: COVID-19 vs. our Networks

[Keith Medcalf]

On Friday, 20 March, 2020 20:43, Mark Tinka  wrote:

>If we go down this path, who's to say which service provider will or
>won't be "targeted" next at the whim of some command & control policy
>maker? Is it a rabbit hole whose top-soil we want to uncover?

Perhaps the "advertizing" and "JavaScript" should be banned from websites 
first.  That would have more effect than fiddling with streaming media services.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.