[NNagain] Internet Education for Non-technorati?

[NNagain] Internet Education for Non-technorati?

[Jack Haverty]

A few days ago I made some comments about the idea of "educating" the 
lawyers, politicians, and other smart, but not necessarily technically 
adept, decision makers.  Today I saw a news story about a recent FCC 
action, to mandate "nutrition labels" on Internet services offered by ISPs:

https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/

This struck me as anecdotal, but a good example of the need for 
education.  Although it's tempting and natural to look at existing 
infrastructures as models for regulating a new one, IMHO the Internet 
does not work like the Food/Agriculture infrastructure does.

For example, the new mandates require ISPs to "label" their products 
with "nutritional" data including "typical" latency, upload, and 
download speeds.   They have until April 2024 to figure it out. I've 
never encountered an ISP who could answer such questions - even the ones 
I was involved in managing.  Marketing can of course create an answer, 
since "typical" is such a vague term.  Figuring out how to attach the 
physical label to their service product may be a problem.

Such labels may not be very helpful to the end user struggling to find 
an ISP that delivers the service needed for some interactive use (audio 
or video conferencing, gaming, home automation, etc.)

Performance on the Internet depends on where the two endpoints are, the 
physical path to get from one to the other, as well as the hardware, 
software, current load, and other aspects of each endpoint, all outside 
the ISPs' control or vision.   Since the two endpoints can be on 
different ISPs, perhaps requiring one or more additional internediate 
ISPs, specifying a "typical" performance from all Points A to all Points 
B is even more challenging.

Switching to the transportation analogy, one might ask your local bus or 
rail company what their typical time is to get from one city to 
another.   If the two cities involved happen to be on their rail or bus 
network, perhaps you can get an answer, but it will still depend on 
where the two endpoints are.  If one or both cities are not on their 
rail network, the travel time might have to include use of other 
"networks" - bus, rental car, airplane, ship, etc.   How long does it 
typically take for you to get from any city on the planet to any other 
city on the planet?

IMHO, rules and regulations for the Internet need to reflect how the 
Internet actually works.  That's why I suggested a focus on education 
for the decision makers.

Jack Haverty

Re: [NNagain] Internet Education for Non-technorati?

[David Bray, PhD]

[-- Attachment #1: Type: text/plain, Size: 4626 bytes --]

I was at a closed-door event discussing these labels about two weeks ago
(right before the potential government shutdown/temporarily averted for
now) - and it was non-attribution, so I can only describe my comments:

(1) the labels risk missing the reality that the Internet and cybersecurity
are not steady state, which begs the question how will they be updated
(2) the labels say nothing about how - even if the company promises to keep
your data private and secure - how good their security practices are
internal to the company? Or what if the company is bought in 5 years?
(3) they use QR-codes to provide additional info, yet we know QR-codes can
be sent to bad links so what if someone replaces a label with a bad link
such that the label itself becomes an exploit?

I think the biggest risks is these we be rolled out, some exploit will
occur that the label didn't consider, consumers will be angry they weren't
"protected" and now we are even in worse shape because the public's trust
has gone further down hill, they angry at the government, and the private
sector feels like the time and energy they spent on the labels was for
naught?

There's also the concern about how do startups roll-out such a label for
their tech in the early iteration phase? How do they afford to do the extra
work for the label vs. a big company (does this become a regulatory moat?)

And let's say we have these labels. Will only consumers with the money to
purchase the more expensive equipment that has more privacy and security
features buy that one - leaving those who cannot afford privacy and
security bad alternatives?

On Wed, Oct 11, 2023 at 1:31 PM Jack Haverty via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> A few days ago I made some comments about the idea of "educating" the
> lawyers, politicians, and other smart, but not necessarily technically
> adept, decision makers.  Today I saw a news story about a recent FCC
> action, to mandate "nutrition labels" on Internet services offered by ISPs:
>
>
> https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/
>
> This struck me as anecdotal, but a good example of the need for
> education.  Although it's tempting and natural to look at existing
> infrastructures as models for regulating a new one, IMHO the Internet
> does not work like the Food/Agriculture infrastructure does.
>
> For example, the new mandates require ISPs to "label" their products
> with "nutritional" data including "typical" latency, upload, and
> download speeds.   They have until April 2024 to figure it out. I've
> never encountered an ISP who could answer such questions - even the ones
> I was involved in managing.  Marketing can of course create an answer,
> since "typical" is such a vague term.  Figuring out how to attach the
> physical label to their service product may be a problem.
>
> Such labels may not be very helpful to the end user struggling to find
> an ISP that delivers the service needed for some interactive use (audio
> or video conferencing, gaming, home automation, etc.)
>
> Performance on the Internet depends on where the two endpoints are, the
> physical path to get from one to the other, as well as the hardware,
> software, current load, and other aspects of each endpoint, all outside
> the ISPs' control or vision.   Since the two endpoints can be on
> different ISPs, perhaps requiring one or more additional internediate
> ISPs, specifying a "typical" performance from all Points A to all Points
> B is even more challenging.
>
> Switching to the transportation analogy, one might ask your local bus or
> rail company what their typical time is to get from one city to
> another.   If the two cities involved happen to be on their rail or bus
> network, perhaps you can get an answer, but it will still depend on
> where the two endpoints are.  If one or both cities are not on their
> rail network, the travel time might have to include use of other
> "networks" - bus, rental car, airplane, ship, etc.   How long does it
> typically take for you to get from any city on the planet to any other
> city on the planet?
>
> IMHO, rules and regulations for the Internet need to reflect how the
> Internet actually works.  That's why I suggested a focus on education
> for the decision makers.
>
> Jack Haverty
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>

[-- Attachment #2: Type: text/html, Size: 5672 bytes --]

Re: [NNagain] Internet Education for Non-technorati?

[Dave Taht]

I think y'all are conflating two different labels here. The nutrition
label was one effort, now being deploye, the other is cybersecurity,
now being discussed.

On the nutrition front...
We successfully fought against "packet loss" being included on the
nutrition label, but as ghu is my witness, I have no idea if a formal
method for declaring "typical latency" was ever formally derived.

https://www.fcc.gov/document/fcc-requires-broadband-providers-display-labels-help-consumers

On Wed, Oct 11, 2023 at 10:39 AM David Bray, PhD via Nnagain
<nnagain@lists.bufferbloat.net> wrote:
>
> I was at a closed-door event discussing these labels about two weeks ago (right before the potential government shutdown/temporarily averted for now) - and it was non-attribution, so I can only describe my comments:
>
> (1) the labels risk missing the reality that the Internet and cybersecurity are not steady state, which begs the question how will they be updated
> (2) the labels say nothing about how - even if the company promises to keep your data private and secure - how good their security practices are internal to the company? Or what if the company is bought in 5 years?
> (3) they use QR-codes to provide additional info, yet we know QR-codes can be sent to bad links so what if someone replaces a label with a bad link such that the label itself becomes an exploit?
>
> I think the biggest risks is these we be rolled out, some exploit will occur that the label didn't consider, consumers will be angry they weren't "protected" and now we are even in worse shape because the public's trust has gone further down hill, they angry at the government, and the private sector feels like the time and energy they spent on the labels was for naught?
>
> There's also the concern about how do startups roll-out such a label for their tech in the early iteration phase? How do they afford to do the extra work for the label vs. a big company (does this become a regulatory moat?)
>
> And let's say we have these labels. Will only consumers with the money to purchase the more expensive equipment that has more privacy and security features buy that one - leaving those who cannot afford privacy and security bad alternatives?
>
> On Wed, Oct 11, 2023 at 1:31 PM Jack Haverty via Nnagain <nnagain@lists.bufferbloat.net> wrote:
>>
>> A few days ago I made some comments about the idea of "educating" the
>> lawyers, politicians, and other smart, but not necessarily technically
>> adept, decision makers.  Today I saw a news story about a recent FCC
>> action, to mandate "nutrition labels" on Internet services offered by ISPs:
>>
>> https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/
>>
>> This struck me as anecdotal, but a good example of the need for
>> education.  Although it's tempting and natural to look at existing
>> infrastructures as models for regulating a new one, IMHO the Internet
>> does not work like the Food/Agriculture infrastructure does.
>>
>> For example, the new mandates require ISPs to "label" their products
>> with "nutritional" data including "typical" latency, upload, and
>> download speeds.   They have until April 2024 to figure it out. I've
>> never encountered an ISP who could answer such questions - even the ones
>> I was involved in managing.  Marketing can of course create an answer,
>> since "typical" is such a vague term.  Figuring out how to attach the
>> physical label to their service product may be a problem.
>>
>> Such labels may not be very helpful to the end user struggling to find
>> an ISP that delivers the service needed for some interactive use (audio
>> or video conferencing, gaming, home automation, etc.)
>>
>> Performance on the Internet depends on where the two endpoints are, the
>> physical path to get from one to the other, as well as the hardware,
>> software, current load, and other aspects of each endpoint, all outside
>> the ISPs' control or vision.   Since the two endpoints can be on
>> different ISPs, perhaps requiring one or more additional internediate
>> ISPs, specifying a "typical" performance from all Points A to all Points
>> B is even more challenging.
>>
>> Switching to the transportation analogy, one might ask your local bus or
>> rail company what their typical time is to get from one city to
>> another.   If the two cities involved happen to be on their rail or bus
>> network, perhaps you can get an answer, but it will still depend on
>> where the two endpoints are.  If one or both cities are not on their
>> rail network, the travel time might have to include use of other
>> "networks" - bus, rental car, airplane, ship, etc.   How long does it
>> typically take for you to get from any city on the planet to any other
>> city on the planet?
>>
>> IMHO, rules and regulations for the Internet need to reflect how the
>> Internet actually works.  That's why I suggested a focus on education
>> for the decision makers.
>>
>> Jack Haverty
>>
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain



-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos

Re: [NNagain] Internet Education for Non-technorati?

[rjmcmahon]

I've added many metrics around latency and one way delays (OWD) in iperf 
2. There is no single type of latency, nor are the measurements scalars. 
(Few will understand violin plots or histograms on labels)

On top of that, a paced flow will have a different e2e latency histogram 
than an as fast as possible (AFAP) flow. They also drive different WiFi 
behaviors. Hence, it's not just a simple arrival rate and service time 
anymore, even for queuing analysis. (Though Little's Law is pretty cool 
and useful for displacement ratings) Throw in BSS managed EDCAs and all 
bets are off.

Bob
> I think y'all are conflating two different labels here. The nutrition
> label was one effort, now being deploye, the other is cybersecurity,
> now being discussed.
> 
> On the nutrition front...
> We successfully fought against "packet loss" being included on the
> nutrition label, but as ghu is my witness, I have no idea if a formal
> method for declaring "typical latency" was ever formally derived.
> 
> https://www.fcc.gov/document/fcc-requires-broadband-providers-display-labels-help-consumers
> 
> On Wed, Oct 11, 2023 at 10:39 AM David Bray, PhD via Nnagain
> <nnagain@lists.bufferbloat.net> wrote:
>> 
>> I was at a closed-door event discussing these labels about two weeks 
>> ago (right before the potential government shutdown/temporarily 
>> averted for now) - and it was non-attribution, so I can only describe 
>> my comments:
>> 
>> (1) the labels risk missing the reality that the Internet and 
>> cybersecurity are not steady state, which begs the question how will 
>> they be updated
>> (2) the labels say nothing about how - even if the company promises to 
>> keep your data private and secure - how good their security practices 
>> are internal to the company? Or what if the company is bought in 5 
>> years?
>> (3) they use QR-codes to provide additional info, yet we know QR-codes 
>> can be sent to bad links so what if someone replaces a label with a 
>> bad link such that the label itself becomes an exploit?
>> 
>> I think the biggest risks is these we be rolled out, some exploit will 
>> occur that the label didn't consider, consumers will be angry they 
>> weren't "protected" and now we are even in worse shape because the 
>> public's trust has gone further down hill, they angry at the 
>> government, and the private sector feels like the time and energy they 
>> spent on the labels was for naught?
>> 
>> There's also the concern about how do startups roll-out such a label 
>> for their tech in the early iteration phase? How do they afford to do 
>> the extra work for the label vs. a big company (does this become a 
>> regulatory moat?)
>> 
>> And let's say we have these labels. Will only consumers with the money 
>> to purchase the more expensive equipment that has more privacy and 
>> security features buy that one - leaving those who cannot afford 
>> privacy and security bad alternatives?
>> 
>> On Wed, Oct 11, 2023 at 1:31 PM Jack Haverty via Nnagain 
>> <nnagain@lists.bufferbloat.net> wrote:
>>> 
>>> A few days ago I made some comments about the idea of "educating" the
>>> lawyers, politicians, and other smart, but not necessarily 
>>> technically
>>> adept, decision makers.  Today I saw a news story about a recent FCC
>>> action, to mandate "nutrition labels" on Internet services offered by 
>>> ISPs:
>>> 
>>> https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/
>>> 
>>> This struck me as anecdotal, but a good example of the need for
>>> education.  Although it's tempting and natural to look at existing
>>> infrastructures as models for regulating a new one, IMHO the Internet
>>> does not work like the Food/Agriculture infrastructure does.
>>> 
>>> For example, the new mandates require ISPs to "label" their products
>>> with "nutritional" data including "typical" latency, upload, and
>>> download speeds.   They have until April 2024 to figure it out. I've
>>> never encountered an ISP who could answer such questions - even the 
>>> ones
>>> I was involved in managing.  Marketing can of course create an 
>>> answer,
>>> since "typical" is such a vague term.  Figuring out how to attach the
>>> physical label to their service product may be a problem.
>>> 
>>> Such labels may not be very helpful to the end user struggling to 
>>> find
>>> an ISP that delivers the service needed for some interactive use 
>>> (audio
>>> or video conferencing, gaming, home automation, etc.)
>>> 
>>> Performance on the Internet depends on where the two endpoints are, 
>>> the
>>> physical path to get from one to the other, as well as the hardware,
>>> software, current load, and other aspects of each endpoint, all 
>>> outside
>>> the ISPs' control or vision.   Since the two endpoints can be on
>>> different ISPs, perhaps requiring one or more additional internediate
>>> ISPs, specifying a "typical" performance from all Points A to all 
>>> Points
>>> B is even more challenging.
>>> 
>>> Switching to the transportation analogy, one might ask your local bus 
>>> or
>>> rail company what their typical time is to get from one city to
>>> another.   If the two cities involved happen to be on their rail or 
>>> bus
>>> network, perhaps you can get an answer, but it will still depend on
>>> where the two endpoints are.  If one or both cities are not on their
>>> rail network, the travel time might have to include use of other
>>> "networks" - bus, rental car, airplane, ship, etc.   How long does it
>>> typically take for you to get from any city on the planet to any 
>>> other
>>> city on the planet?
>>> 
>>> IMHO, rules and regulations for the Internet need to reflect how the
>>> Internet actually works.  That's why I suggested a focus on education
>>> for the decision makers.
>>> 
>>> Jack Haverty
>>> 
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[Dick Roy]

[-- Attachment #1: Type: text/plain, Size: 7511 bytes --]

 

 

-----Original Message-----
From: Nnagain [mailto:nnagain-bounces@lists.bufferbloat.net] On Behalf Of rjmcmahon via Nnagain
Sent: Wednesday, October 11, 2023 11:18 AM
To: Network Neutrality is back! Let´s make the technical aspects heard this time!
Cc: rjmcmahon; Nick Feamster
Subject: Re: [NNagain] Internet Education for Non-technorati?

 

I've added many metrics around latency and one way delays (OWD) in iperf 

2. There is no single type of latency, nor are the measurements scalars. 

(Few will understand violin plots or histograms on labels)

 

On top of that, a paced flow will have a different e2e latency histogram 

than an as fast as possible (AFAP) flow. They also drive different WiFi 

behaviors. Hence, it's not just a simple arrival rate and service time 

anymore, even for queuing analysis. (Though Little's Law is pretty cool 

and useful for displacement ratings) Throw in BSS managed EDCAs and all 

bets are off.

[RR] Wouldn’t the issue of EDCAs (i.e.different queues for different priority classes with different tx parameters for each), just make the analysis (more) “multidimensional”?  Might it be possible to model such scenarios as N different collocated bridges/routers), one for each access category?  Does any of what I just said make any sense in this context? :-) :-)

 

RR

 

Bob

> I think y'all are conflating two different labels here. The nutrition

> label was one effort, now being deploye, the other is cybersecurity,

> now being discussed.

> 

> On the nutrition front...

> We successfully fought against "packet loss" being included on the

> nutrition label, but as ghu is my witness, I have no idea if a formal

> method for declaring "typical latency" was ever formally derived.

> 

> https://www.fcc.gov/document/fcc-requires-broadband-providers-display-labels-help-consumers

> 

> On Wed, Oct 11, 2023 at 10:39 AM David Bray, PhD via Nnagain

> <nnagain@lists.bufferbloat.net> wrote:

>> 

>> I was at a closed-door event discussing these labels about two weeks 

>> ago (right before the potential government shutdown/temporarily 

>> averted for now) - and it was non-attribution, so I can only describe 

>> my comments:

>> 

>> (1) the labels risk missing the reality that the Internet and 

>> cybersecurity are not steady state, which begs the question how will 

>> they be updated

>> (2) the labels say nothing about how - even if the company promises to 

>> keep your data private and secure - how good their security practices 

>> are internal to the company? Or what if the company is bought in 5 

>> years?

>> (3) they use QR-codes to provide additional info, yet we know QR-codes 

>> can be sent to bad links so what if someone replaces a label with a 

>> bad link such that the label itself becomes an exploit?

>> 

>> I think the biggest risks is these we be rolled out, some exploit will 

>> occur that the label didn't consider, consumers will be angry they 

>> weren't "protected" and now we are even in worse shape because the 

>> public's trust has gone further down hill, they angry at the 

>> government, and the private sector feels like the time and energy they 

>> spent on the labels was for naught?

>> 

>> There's also the concern about how do startups roll-out such a label 

>> for their tech in the early iteration phase? How do they afford to do 

>> the extra work for the label vs. a big company (does this become a 

>> regulatory moat?)

>> 

>> And let's say we have these labels. Will only consumers with the money 

>> to purchase the more expensive equipment that has more privacy and 

>> security features buy that one - leaving those who cannot afford 

>> privacy and security bad alternatives?

>> 

>> On Wed, Oct 11, 2023 at 1:31 PM Jack Haverty via Nnagain 

>> <nnagain@lists.bufferbloat.net> wrote:

>>> 

>>> A few days ago I made some comments about the idea of "educating" the

>>> lawyers, politicians, and other smart, but not necessarily 

>>> technically

>>> adept, decision makers.  Today I saw a news story about a recent FCC

>>> action, to mandate "nutrition labels" on Internet services offered by 

>>> ISPs:

>>> 

>>> https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/

>>> 

>>> This struck me as anecdotal, but a good example of the need for

>>> education.  Although it's tempting and natural to look at existing

>>> infrastructures as models for regulating a new one, IMHO the Internet

>>> does not work like the Food/Agriculture infrastructure does.

>>> 

>>> For example, the new mandates require ISPs to "label" their products

>>> with "nutritional" data including "typical" latency, upload, and

>>> download speeds.   They have until April 2024 to figure it out. I've

>>> never encountered an ISP who could answer such questions - even the 

>>> ones

>>> I was involved in managing.  Marketing can of course create an 

>>> answer,

>>> since "typical" is such a vague term.  Figuring out how to attach the

>>> physical label to their service product may be a problem.

>>> 

>>> Such labels may not be very helpful to the end user struggling to 

>>> find

>>> an ISP that delivers the service needed for some interactive use 

>>> (audio

>>> or video conferencing, gaming, home automation, etc.)

>>> 

>>> Performance on the Internet depends on where the two endpoints are, 

>>> the

>>> physical path to get from one to the other, as well as the hardware,

>>> software, current load, and other aspects of each endpoint, all 

>>> outside

>>> the ISPs' control or vision.   Since the two endpoints can be on

>>> different ISPs, perhaps requiring one or more additional internediate

>>> ISPs, specifying a "typical" performance from all Points A to all 

>>> Points

>>> B is even more challenging.

>>> 

>>> Switching to the transportation analogy, one might ask your local bus 

>>> or

>>> rail company what their typical time is to get from one city to

>>> another.   If the two cities involved happen to be on their rail or 

>>> bus

>>> network, perhaps you can get an answer, but it will still depend on

>>> where the two endpoints are.  If one or both cities are not on their

>>> rail network, the travel time might have to include use of other

>>> "networks" - bus, rental car, airplane, ship, etc.   How long does it

>>> typically take for you to get from any city on the planet to any 

>>> other

>>> city on the planet?

>>> 

>>> IMHO, rules and regulations for the Internet need to reflect how the

>>> Internet actually works.  That's why I suggested a focus on education

>>> for the decision makers.

>>> 

>>> Jack Haverty

>>> 

>>> _______________________________________________

>>> Nnagain mailing list

>>> Nnagain@lists.bufferbloat.net

>>> https://lists.bufferbloat.net/listinfo/nnagain

>> 

>> _______________________________________________

>> Nnagain mailing list

>> Nnagain@lists.bufferbloat.net

>> https://lists.bufferbloat.net/listinfo/nnagain

_______________________________________________

Nnagain mailing list

Nnagain@lists.bufferbloat.net

https://lists.bufferbloat.net/listinfo/nnagain


[-- Attachment #2: Type: text/html, Size: 27084 bytes --]

Re: [NNagain] Internet Education for Non-technorati?

[rjmcmahon]

Yes, EDCAs are multidimensional. The coupling of EDCA to a DSCP field, 
Access Class (AC) or MAC queue is just an engineering thing. The EDCA is 
really just for an upcoming access arbitration and doesn't have to be 
held constant. And the values are under control of the WiFi BSS manager.

What's a WiFi BSS manager one might ask? It's an unfilled role that the 
standards engineers assumed would occur, yet are networking roles are 
under staffed all over the planet. The default EDCAs are just some made 
up numbers that have no simulation or other backing - though many think 
they're gold or something - which they're not.

There are so many things at play just for WiFi performance yet alone 
e2e. I wouldn't know where to start for a consumer label. Even marketing 
terms like WiFi 6, 6e and 7 seem to mostly add confusion.

Then engineers design for the tests because what else can they do? And 
the tests struggle to represent any kind of reality. Labels are likely 
going to have a similar affect.

Even the basics of capacity and latency are not understood by consumers. 
The voice engineers created mean opinion scores which I don't think 
consumers ever cared about. Then we talk about quality of experience 
(QoE) as if it were a mathematical term, which it isn't.

Bob
> -----Original Message-----
> From: Nnagain [mailto:nnagain-bounces@lists.bufferbloat.net] On Behalf
> Of rjmcmahon via Nnagain
> Sent: Wednesday, October 11, 2023 11:18 AM
> To: Network Neutrality is back! Let´s make the technical aspects
> heard this time!
> Cc: rjmcmahon; Nick Feamster
> Subject: Re: [NNagain] Internet Education for Non-technorati?
> 
> I've added many metrics around latency and one way delays (OWD) in
> iperf
> 
> 2. There is no single type of latency, nor are the measurements
> scalars.
> 
> (Few will understand violin plots or histograms on labels)
> 
> On top of that, a paced flow will have a different e2e latency
> histogram
> 
> than an as fast as possible (AFAP) flow. They also drive different
> WiFi
> 
> behaviors. Hence, it's not just a simple arrival rate and service time
> 
> 
> anymore, even for queuing analysis. (Though Little's Law is pretty
> cool
> 
> and useful for displacement ratings) Throw in BSS managed EDCAs and
> all
> 
> bets are off.
> 
> _[RR] Wouldn’t the issue of EDCAs (i.e.different queues for
> different priority classes with different tx parameters for each),
> just make the analysis (more) “multidimensional”?  Might it be
> possible to model such scenarios as N different collocated
> bridges/routers), one for each access category?  Does any of what I
> just said make any sense in this context? __J __J_
> 
> _ _
> 
> _RR_
> 
> Bob
> 
>> I think y'all are conflating two different labels here. The
> nutrition
> 
>> label was one effort, now being deploye, the other is cybersecurity,
> 
> 
>> now being discussed.
> 
>> 
> 
>> On the nutrition front...
> 
>> We successfully fought against "packet loss" being included on the
> 
>> nutrition label, but as ghu is my witness, I have no idea if a
> formal
> 
>> method for declaring "typical latency" was ever formally derived.
> 
>> 
> 
>> 
> https://www.fcc.gov/document/fcc-requires-broadband-providers-display-labels-help-consumers
> 
> 
>> 
> 
>> On Wed, Oct 11, 2023 at 10:39 AM David Bray, PhD via Nnagain
> 
>> <nnagain@lists.bufferbloat.net> wrote:
> 
>>> 
> 
>>> I was at a closed-door event discussing these labels about two
> weeks
> 
>>> ago (right before the potential government shutdown/temporarily
> 
>>> averted for now) - and it was non-attribution, so I can only
> describe
> 
>>> my comments:
> 
>>> 
> 
>>> (1) the labels risk missing the reality that the Internet and
> 
>>> cybersecurity are not steady state, which begs the question how
> will
> 
>>> they be updated
> 
>>> (2) the labels say nothing about how - even if the company promises
> to
> 
>>> keep your data private and secure - how good their security
> practices
> 
>>> are internal to the company? Or what if the company is bought in 5
> 
>>> years?
> 
>>> (3) they use QR-codes to provide additional info, yet we know
> QR-codes
> 
>>> can be sent to bad links so what if someone replaces a label with a
> 
> 
>>> bad link such that the label itself becomes an exploit?
> 
>>> 
> 
>>> I think the biggest risks is these we be rolled out, some exploit
> will
> 
>>> occur that the label didn't consider, consumers will be angry they
> 
>>> weren't "protected" and now we are even in worse shape because the
> 
>>> public's trust has gone further down hill, they angry at the
> 
>>> government, and the private sector feels like the time and energy
> they
> 
>>> spent on the labels was for naught?
> 
>>> 
> 
>>> There's also the concern about how do startups roll-out such a
> label
> 
>>> for their tech in the early iteration phase? How do they afford to
> do
> 
>>> the extra work for the label vs. a big company (does this become a
> 
>>> regulatory moat?)
> 
>>> 
> 
>>> And let's say we have these labels. Will only consumers with the
> money
> 
>>> to purchase the more expensive equipment that has more privacy and
> 
>>> security features buy that one - leaving those who cannot afford
> 
>>> privacy and security bad alternatives?
> 
>>> 
> 
>>> On Wed, Oct 11, 2023 at 1:31 PM Jack Haverty via Nnagain
> 
>>> <nnagain@lists.bufferbloat.net> wrote:
> 
>>>> 
> 
>>>> A few days ago I made some comments about the idea of "educating"
> the
> 
>>>> lawyers, politicians, and other smart, but not necessarily
> 
>>>> technically
> 
>>>> adept, decision makers.  Today I saw a news story about a recent
> FCC
> 
>>>> action, to mandate "nutrition labels" on Internet services offered
> by
> 
>>>> ISPs:
> 
>>>> 
> 
>>>> 
> https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/
> 
> 
>>>> 
> 
>>>> This struck me as anecdotal, but a good example of the need for
> 
>>>> education.  Although it's tempting and natural to look at existing
> 
> 
>>>> infrastructures as models for regulating a new one, IMHO the
> Internet
> 
>>>> does not work like the Food/Agriculture infrastructure does.
> 
>>>> 
> 
>>>> For example, the new mandates require ISPs to "label" their
> products
> 
>>>> with "nutritional" data including "typical" latency, upload, and
> 
>>>> download speeds.   They have until April 2024 to figure it out.
> I've
> 
>>>> never encountered an ISP who could answer such questions - even
> the
> 
>>>> ones
> 
>>>> I was involved in managing.  Marketing can of course create an
> 
>>>> answer,
> 
>>>> since "typical" is such a vague term.  Figuring out how to attach
> the
> 
>>>> physical label to their service product may be a problem.
> 
>>>> 
> 
>>>> Such labels may not be very helpful to the end user struggling to
> 
>>>> find
> 
>>>> an ISP that delivers the service needed for some interactive use
> 
>>>> (audio
> 
>>>> or video conferencing, gaming, home automation, etc.)
> 
>>>> 
> 
>>>> Performance on the Internet depends on where the two endpoints
> are,
> 
>>>> the
> 
>>>> physical path to get from one to the other, as well as the
> hardware,
> 
>>>> software, current load, and other aspects of each endpoint, all
> 
>>>> outside
> 
>>>> the ISPs' control or vision.   Since the two endpoints can be on
> 
>>>> different ISPs, perhaps requiring one or more additional
> internediate
> 
>>>> ISPs, specifying a "typical" performance from all Points A to all
> 
>>>> Points
> 
>>>> B is even more challenging.
> 
>>>> 
> 
>>>> Switching to the transportation analogy, one might ask your local
> bus
> 
>>>> or
> 
>>>> rail company what their typical time is to get from one city to
> 
>>>> another.   If the two cities involved happen to be on their rail
> or
> 
>>>> bus
> 
>>>> network, perhaps you can get an answer, but it will still depend
> on
> 
>>>> where the two endpoints are.  If one or both cities are not on
> their
> 
>>>> rail network, the travel time might have to include use of other
> 
>>>> "networks" - bus, rental car, airplane, ship, etc.   How long does
> it
> 
>>>> typically take for you to get from any city on the planet to any
> 
>>>> other
> 
>>>> city on the planet?
> 
>>>> 
> 
>>>> IMHO, rules and regulations for the Internet need to reflect how
> the
> 
>>>> Internet actually works.  That's why I suggested a focus on
> education
> 
>>>> for the decision makers.
> 
>>>> 
> 
>>>> Jack Haverty
> 
>>>> 
> 
>>>> _______________________________________________
> 
>>>> Nnagain mailing list
> 
>>>> Nnagain@lists.bufferbloat.net
> 
>>>> https://lists.bufferbloat.net/listinfo/nnagain
> 
>>> 
> 
>>> _______________________________________________
> 
>>> Nnagain mailing list
> 
>>> Nnagain@lists.bufferbloat.net
> 
>>> https://lists.bufferbloat.net/listinfo/nnagain
> 
> _______________________________________________
> 
> Nnagain mailing list
> 
> Nnagain@lists.bufferbloat.net
> 
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[Dick Roy]

[-- Attachment #1: Type: text/plain, Size: 10863 bytes --]

 

 

-----Original Message-----
From: rjmcmahon [mailto:rjmcmahon@rjmcmahon.com] 
Sent: Wednesday, October 11, 2023 11:50 AM
To: dickroy@alum.mit.edu
Cc: 'Network Neutrality is back! Let´s make the technical aspects heard this time!'; 'Nick Feamster'
Subject: Re: [NNagain] Internet Education for Non-technorati?

 

Yes, EDCAs are multidimensional. The coupling of EDCA to a DSCP field, 

Access Class (AC) or MAC queue is just an engineering thing. The EDCA is 

really just for an upcoming access arbitration and doesn't have to be 

held constant. And the values are under control of the WiFi BSS manager.

[RR] Yup!

 

What's a WiFi BSS manager one might ask? It's an unfilled role that the 

standards engineers assumed would occur, yet are networking roles are 

under staffed all over the planet. The default EDCAs are just some made 

up numbers that have no simulation or other backing - though many think 

they're gold or something - which they're not.

[RR] We (ITS/DSRC people) did simulations to come up with our own (802.11p) default set, and as you point it, it’s just a default set and therefore subject to change! Gold it is not! :-) 

 

There are so many things at play just for WiFi performance yet alone 

e2e. I wouldn't know where to start for a consumer label. Even marketing 

terms like WiFi 6, 6e and 7 seem to mostly add confusion.

[RR] Yup!

 

Then engineers design for the tests because what else can they do? And 

the tests struggle to represent any kind of reality. Labels are likely 

going to have a similar affect.

[RR] Couldn’t agree more!

 

Even the basics of capacity and latency are not understood by consumers. 

[RR] In their defense, they are both more than two syllable words! :-) :-)

The voice engineers created mean opinion scores which I don't think 

consumers ever cared about.

[RR] And the engineers really couldn’t explain it to them either! :-)

 Then we talk about quality of experience 

(QoE) as if it were a mathematical term, which it isn't.

[RR] Sure isn’t as far as I know!

 

RR

 

Bob

> -----Original Message-----

> From: Nnagain [mailto:nnagain-bounces@lists.bufferbloat.net] On Behalf

> Of rjmcmahon via Nnagain

> Sent: Wednesday, October 11, 2023 11:18 AM

> To: Network Neutrality is back! Let´s make the technical aspects

> heard this time!

> Cc: rjmcmahon; Nick Feamster

> Subject: Re: [NNagain] Internet Education for Non-technorati?

> 

> I've added many metrics around latency and one way delays (OWD) in

> iperf

> 

> 2. There is no single type of latency, nor are the measurements

> scalars.

> 

> (Few will understand violin plots or histograms on labels)

> 

> On top of that, a paced flow will have a different e2e latency

> histogram

> 

> than an as fast as possible (AFAP) flow. They also drive different

> WiFi

> 

> behaviors. Hence, it's not just a simple arrival rate and service time

> 

> 

> anymore, even for queuing analysis. (Though Little's Law is pretty

> cool

> 

> and useful for displacement ratings) Throw in BSS managed EDCAs and

> all

> 

> bets are off.

> 

> _[RR] Wouldn’t the issue of EDCAs (i.e.different queues for

> different priority classes with different tx parameters for each),

> just make the analysis (more) “multidimensional”?  Might it be

> possible to model such scenarios as N different collocated

> bridges/routers), one for each access category?  Does any of what I

> just said make any sense in this context? __J __J_

> 

> _ _

> 

> _RR_

> 

> Bob

> 

>> I think y'all are conflating two different labels here. The

> nutrition

> 

>> label was one effort, now being deploye, the other is cybersecurity,

> 

> 

>> now being discussed.

> 

>> 

> 

>> On the nutrition front...

> 

>> We successfully fought against "packet loss" being included on the

> 

>> nutrition label, but as ghu is my witness, I have no idea if a

> formal

> 

>> method for declaring "typical latency" was ever formally derived.

> 

>> 

> 

>> 

> https://www.fcc.gov/document/fcc-requires-broadband-providers-display-labels-help-consumers

> 

> 

>> 

> 

>> On Wed, Oct 11, 2023 at 10:39 AM David Bray, PhD via Nnagain

> 

>> <nnagain@lists.bufferbloat.net> wrote:

> 

>>> 

> 

>>> I was at a closed-door event discussing these labels about two

> weeks

> 

>>> ago (right before the potential government shutdown/temporarily

> 

>>> averted for now) - and it was non-attribution, so I can only

> describe

> 

>>> my comments:

> 

>>> 

> 

>>> (1) the labels risk missing the reality that the Internet and

> 

>>> cybersecurity are not steady state, which begs the question how

> will

> 

>>> they be updated

> 

>>> (2) the labels say nothing about how - even if the company promises

> to

> 

>>> keep your data private and secure - how good their security

> practices

> 

>>> are internal to the company? Or what if the company is bought in 5

> 

>>> years?

> 

>>> (3) they use QR-codes to provide additional info, yet we know

> QR-codes

> 

>>> can be sent to bad links so what if someone replaces a label with a

> 

> 

>>> bad link such that the label itself becomes an exploit?

> 

>>> 

> 

>>> I think the biggest risks is these we be rolled out, some exploit

> will

> 

>>> occur that the label didn't consider, consumers will be angry they

> 

>>> weren't "protected" and now we are even in worse shape because the

> 

>>> public's trust has gone further down hill, they angry at the

> 

>>> government, and the private sector feels like the time and energy

> they

> 

>>> spent on the labels was for naught?

> 

>>> 

> 

>>> There's also the concern about how do startups roll-out such a

> label

> 

>>> for their tech in the early iteration phase? How do they afford to

> do

> 

>>> the extra work for the label vs. a big company (does this become a

> 

>>> regulatory moat?)

> 

>>> 

> 

>>> And let's say we have these labels. Will only consumers with the

> money

> 

>>> to purchase the more expensive equipment that has more privacy and

> 

>>> security features buy that one - leaving those who cannot afford

> 

>>> privacy and security bad alternatives?

> 

>>> 

> 

>>> On Wed, Oct 11, 2023 at 1:31 PM Jack Haverty via Nnagain

> 

>>> <nnagain@lists.bufferbloat.net> wrote:

> 

>>>> 

> 

>>>> A few days ago I made some comments about the idea of "educating"

> the

> 

>>>> lawyers, politicians, and other smart, but not necessarily

> 

>>>> technically

> 

>>>> adept, decision makers.  Today I saw a news story about a recent

> FCC

> 

>>>> action, to mandate "nutrition labels" on Internet services offered

> by

> 

>>>> ISPs:

> 

>>>> 

> 

>>>> 

> https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/

> 

> 

>>>> 

> 

>>>> This struck me as anecdotal, but a good example of the need for

> 

>>>> education.  Although it's tempting and natural to look at existing

> 

> 

>>>> infrastructures as models for regulating a new one, IMHO the

> Internet

> 

>>>> does not work like the Food/Agriculture infrastructure does.

> 

>>>> 

> 

>>>> For example, the new mandates require ISPs to "label" their

> products

> 

>>>> with "nutritional" data including "typical" latency, upload, and

> 

>>>> download speeds.   They have until April 2024 to figure it out.

> I've

> 

>>>> never encountered an ISP who could answer such questions - even

> the

> 

>>>> ones

> 

>>>> I was involved in managing.  Marketing can of course create an

> 

>>>> answer,

> 

>>>> since "typical" is such a vague term.  Figuring out how to attach

> the

> 

>>>> physical label to their service product may be a problem.

> 

>>>> 

> 

>>>> Such labels may not be very helpful to the end user struggling to

> 

>>>> find

> 

>>>> an ISP that delivers the service needed for some interactive use

> 

>>>> (audio

> 

>>>> or video conferencing, gaming, home automation, etc.)

> 

>>>> 

> 

>>>> Performance on the Internet depends on where the two endpoints

> are,

> 

>>>> the

> 

>>>> physical path to get from one to the other, as well as the

> hardware,

> 

>>>> software, current load, and other aspects of each endpoint, all

> 

>>>> outside

> 

>>>> the ISPs' control or vision.   Since the two endpoints can be on

> 

>>>> different ISPs, perhaps requiring one or more additional

> internediate

> 

>>>> ISPs, specifying a "typical" performance from all Points A to all

> 

>>>> Points

> 

>>>> B is even more challenging.

> 

>>>> 

> 

>>>> Switching to the transportation analogy, one might ask your local

> bus

> 

>>>> or

> 

>>>> rail company what their typical time is to get from one city to

> 

>>>> another.   If the two cities involved happen to be on their rail

> or

> 

>>>> bus

> 

>>>> network, perhaps you can get an answer, but it will still depend

> on

> 

>>>> where the two endpoints are.  If one or both cities are not on

> their

> 

>>>> rail network, the travel time might have to include use of other

> 

>>>> "networks" - bus, rental car, airplane, ship, etc.   How long does

> it

> 

>>>> typically take for you to get from any city on the planet to any

> 

>>>> other

> 

>>>> city on the planet?

> 

>>>> 

> 

>>>> IMHO, rules and regulations for the Internet need to reflect how

> the

> 

>>>> Internet actually works.  That's why I suggested a focus on

> education

> 

>>>> for the decision makers.

> 

>>>> 

> 

>>>> Jack Haverty

> 

>>>> 

> 

>>>> _______________________________________________

> 

>>>> Nnagain mailing list

> 

>>>> Nnagain@lists.bufferbloat.net

> 

>>>> https://lists.bufferbloat.net/listinfo/nnagain

> 

>>> 

> 

>>> _______________________________________________

> 

>>> Nnagain mailing list

> 

>>> Nnagain@lists.bufferbloat.net

> 

>>> https://lists.bufferbloat.net/listinfo/nnagain

> 

> _______________________________________________

> 

> Nnagain mailing list

> 

> Nnagain@lists.bufferbloat.net

> 

> https://lists.bufferbloat.net/listinfo/nnagain


[-- Attachment #2: Type: text/html, Size: 58750 bytes --]

Re: [NNagain] Internet Education for Non-technorati?

[Sebastian Moeller]

Hi Bob,


> On Oct 11, 2023, at 20:49, rjmcmahon via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> 
> Yes, EDCAs are multidimensional. The coupling of EDCA to a DSCP field, Access Class (AC) or MAC queue is just an engineering thing. The EDCA is really just for an upcoming access arbitration and doesn't have to be held constant. And the values are under control of the WiFi BSS manager.
> 
> What's a WiFi BSS manager one might ask? It's an unfilled role that the standards engineers assumed would occur, yet are networking roles are under staffed all over the planet. The default EDCAs are just some made up numbers that have no simulation or other backing - though many think they're gold or something - which they're not.
> 
> There are so many things at play just for WiFi performance yet alone e2e. I wouldn't know where to start for a consumer label. Even marketing terms like WiFi 6, 6e and 7 seem to mostly add confusion.
> 
> Then engineers design for the tests because what else can they do? And the tests struggle to represent any kind of reality. Labels are likely going to have a similar affect.

	[SM] And this is why it matters how such labels are to be enforced... if the capacity numbers can be checked by end users against reference servers in a adifferent AS than any good-faith effort of engineers to make the test work sufficiently well will also help with general internet access. With good-faith I mean I exclude stunts like ISPs disabling the per user traffic shaper for the duration of a detected test, or treat test traffic with higher priority...

> Even the basics of capacity and latency are not understood by consumers.

	[SM] There are efforts under way to make end users more conscious about latency issues though, like apple's RPM.


> The voice engineers created mean opinion scores which I don't think consumers ever cared about.

	[SM] Why should they if they can directly judge the quality of their VoIP calls? Sure engineers need something easier to come by than asking end users about perceived quality and hence invented a system to essentially predict user judgements based on a few measurable parameters. But as far as i understand MOS is a simulation of end users that is better suited to the normal engineering process than doing psychoacoustic experiments with end-users, no?

> Then we talk about quality of experience (QoE) as if it were a mathematical term, which it isn't.

	[SM] Measuring experinence, aka subjective perception, is simply a hard problem.

Regards
	Sebastian


> 
> Bob
>> -----Original Message-----
>> From: Nnagain [mailto:nnagain-bounces@lists.bufferbloat.net] On Behalf
>> Of rjmcmahon via Nnagain
>> Sent: Wednesday, October 11, 2023 11:18 AM
>> To: Network Neutrality is back! Let´s make the technical aspects
>> heard this time!
>> Cc: rjmcmahon; Nick Feamster
>> Subject: Re: [NNagain] Internet Education for Non-technorati?
>> I've added many metrics around latency and one way delays (OWD) in
>> iperf
>> 2. There is no single type of latency, nor are the measurements
>> scalars.
>> (Few will understand violin plots or histograms on labels)
>> On top of that, a paced flow will have a different e2e latency
>> histogram
>> than an as fast as possible (AFAP) flow. They also drive different
>> WiFi
>> behaviors. Hence, it's not just a simple arrival rate and service time
>> anymore, even for queuing analysis. (Though Little's Law is pretty
>> cool
>> and useful for displacement ratings) Throw in BSS managed EDCAs and
>> all
>> bets are off.
>> _[RR] Wouldn’t the issue of EDCAs (i.e.different queues for
>> different priority classes with different tx parameters for each),
>> just make the analysis (more) “multidimensional”?  Might it be
>> possible to model such scenarios as N different collocated
>> bridges/routers), one for each access category?  Does any of what I
>> just said make any sense in this context? __J __J_
>> _ _
>> _RR_
>> Bob
>>> I think y'all are conflating two different labels here. The
>> nutrition
>>> label was one effort, now being deploye, the other is cybersecurity,
>>> now being discussed.
>>> On the nutrition front...
>>> We successfully fought against "packet loss" being included on the
>>> nutrition label, but as ghu is my witness, I have no idea if a
>> formal
>>> method for declaring "typical latency" was ever formally derived.
>> https://www.fcc.gov/document/fcc-requires-broadband-providers-display-labels-help-consumers
>>> On Wed, Oct 11, 2023 at 10:39 AM David Bray, PhD via Nnagain
>>> <nnagain@lists.bufferbloat.net> wrote:
>>>> I was at a closed-door event discussing these labels about two
>> weeks
>>>> ago (right before the potential government shutdown/temporarily
>>>> averted for now) - and it was non-attribution, so I can only
>> describe
>>>> my comments:
>>>> (1) the labels risk missing the reality that the Internet and
>>>> cybersecurity are not steady state, which begs the question how
>> will
>>>> they be updated
>>>> (2) the labels say nothing about how - even if the company promises
>> to
>>>> keep your data private and secure - how good their security
>> practices
>>>> are internal to the company? Or what if the company is bought in 5
>>>> years?
>>>> (3) they use QR-codes to provide additional info, yet we know
>> QR-codes
>>>> can be sent to bad links so what if someone replaces a label with a
>>>> bad link such that the label itself becomes an exploit?
>>>> I think the biggest risks is these we be rolled out, some exploit
>> will
>>>> occur that the label didn't consider, consumers will be angry they
>>>> weren't "protected" and now we are even in worse shape because the
>>>> public's trust has gone further down hill, they angry at the
>>>> government, and the private sector feels like the time and energy
>> they
>>>> spent on the labels was for naught?
>>>> There's also the concern about how do startups roll-out such a
>> label
>>>> for their tech in the early iteration phase? How do they afford to
>> do
>>>> the extra work for the label vs. a big company (does this become a
>>>> regulatory moat?)
>>>> And let's say we have these labels. Will only consumers with the
>> money
>>>> to purchase the more expensive equipment that has more privacy and
>>>> security features buy that one - leaving those who cannot afford
>>>> privacy and security bad alternatives?
>>>> On Wed, Oct 11, 2023 at 1:31 PM Jack Haverty via Nnagain
>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>> A few days ago I made some comments about the idea of "educating"
>> the
>>>>> lawyers, politicians, and other smart, but not necessarily
>>>>> technically
>>>>> adept, decision makers.  Today I saw a news story about a recent
>> FCC
>>>>> action, to mandate "nutrition labels" on Internet services offered
>> by
>>>>> ISPs:
>> https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/
>>>>> This struck me as anecdotal, but a good example of the need for
>>>>> education.  Although it's tempting and natural to look at existing
>>>>> infrastructures as models for regulating a new one, IMHO the
>> Internet
>>>>> does not work like the Food/Agriculture infrastructure does.
>>>>> For example, the new mandates require ISPs to "label" their
>> products
>>>>> with "nutritional" data including "typical" latency, upload, and
>>>>> download speeds.   They have until April 2024 to figure it out.
>> I've
>>>>> never encountered an ISP who could answer such questions - even
>> the
>>>>> ones
>>>>> I was involved in managing.  Marketing can of course create an
>>>>> answer,
>>>>> since "typical" is such a vague term.  Figuring out how to attach
>> the
>>>>> physical label to their service product may be a problem.
>>>>> Such labels may not be very helpful to the end user struggling to
>>>>> find
>>>>> an ISP that delivers the service needed for some interactive use
>>>>> (audio
>>>>> or video conferencing, gaming, home automation, etc.)
>>>>> Performance on the Internet depends on where the two endpoints
>> are,
>>>>> the
>>>>> physical path to get from one to the other, as well as the
>> hardware,
>>>>> software, current load, and other aspects of each endpoint, all
>>>>> outside
>>>>> the ISPs' control or vision.   Since the two endpoints can be on
>>>>> different ISPs, perhaps requiring one or more additional
>> internediate
>>>>> ISPs, specifying a "typical" performance from all Points A to all
>>>>> Points
>>>>> B is even more challenging.
>>>>> Switching to the transportation analogy, one might ask your local
>> bus
>>>>> or
>>>>> rail company what their typical time is to get from one city to
>>>>> another.   If the two cities involved happen to be on their rail
>> or
>>>>> bus
>>>>> network, perhaps you can get an answer, but it will still depend
>> on
>>>>> where the two endpoints are.  If one or both cities are not on
>> their
>>>>> rail network, the travel time might have to include use of other
>>>>> "networks" - bus, rental car, airplane, ship, etc.   How long does
>> it
>>>>> typically take for you to get from any city on the planet to any
>>>>> other
>>>>> city on the planet?
>>>>> IMHO, rules and regulations for the Internet need to reflect how
>> the
>>>>> Internet actually works.  That's why I suggested a focus on
>> education
>>>>> for the decision makers.
>>>>> Jack Haverty
>>>>> _______________________________________________
>>>>> Nnagain mailing list
>>>>> Nnagain@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[David Bray, PhD]

[-- Attachment #1: Type: text/plain, Size: 6405 bytes --]

Are we talking about the one that modelled after the label from CMU (they
showed some prototypes, there would be about 10-15 pieces of information on
the label followed by a QR code to get the rest), here's a link - and the
concerns I have apply to this:

https://news.pantheon.cmu.edu/stories/archives/2023/july/cylab-presents-at-white-houses-launch-of-new-iot-cybersecurity-labeling-system

https://www.securityindustry.org/2023/09/12/the-fccs-u-s-cyber-trust-mark-proposal-what-it-means-for-the-security-industry/

On Wed, Oct 11, 2023 at 2:06 PM Dave Taht <dave.taht@gmail.com> wrote:

> I think y'all are conflating two different labels here. The nutrition
> label was one effort, now being deploye, the other is cybersecurity,
> now being discussed.
>
> On the nutrition front...
> We successfully fought against "packet loss" being included on the
> nutrition label, but as ghu is my witness, I have no idea if a formal
> method for declaring "typical latency" was ever formally derived.
>
>
> https://www.fcc.gov/document/fcc-requires-broadband-providers-display-labels-help-consumers
>
> On Wed, Oct 11, 2023 at 10:39 AM David Bray, PhD via Nnagain
> <nnagain@lists.bufferbloat.net> wrote:
> >
> > I was at a closed-door event discussing these labels about two weeks ago
> (right before the potential government shutdown/temporarily averted for
> now) - and it was non-attribution, so I can only describe my comments:
> >
> > (1) the labels risk missing the reality that the Internet and
> cybersecurity are not steady state, which begs the question how will they
> be updated
> > (2) the labels say nothing about how - even if the company promises to
> keep your data private and secure - how good their security practices are
> internal to the company? Or what if the company is bought in 5 years?
> > (3) they use QR-codes to provide additional info, yet we know QR-codes
> can be sent to bad links so what if someone replaces a label with a bad
> link such that the label itself becomes an exploit?
> >
> > I think the biggest risks is these we be rolled out, some exploit will
> occur that the label didn't consider, consumers will be angry they weren't
> "protected" and now we are even in worse shape because the public's trust
> has gone further down hill, they angry at the government, and the private
> sector feels like the time and energy they spent on the labels was for
> naught?
> >
> > There's also the concern about how do startups roll-out such a label for
> their tech in the early iteration phase? How do they afford to do the extra
> work for the label vs. a big company (does this become a regulatory moat?)
> >
> > And let's say we have these labels. Will only consumers with the money
> to purchase the more expensive equipment that has more privacy and security
> features buy that one - leaving those who cannot afford privacy and
> security bad alternatives?
> >
> > On Wed, Oct 11, 2023 at 1:31 PM Jack Haverty via Nnagain <
> nnagain@lists.bufferbloat.net> wrote:
> >>
> >> A few days ago I made some comments about the idea of "educating" the
> >> lawyers, politicians, and other smart, but not necessarily technically
> >> adept, decision makers.  Today I saw a news story about a recent FCC
> >> action, to mandate "nutrition labels" on Internet services offered by
> ISPs:
> >>
> >>
> https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/
> >>
> >> This struck me as anecdotal, but a good example of the need for
> >> education.  Although it's tempting and natural to look at existing
> >> infrastructures as models for regulating a new one, IMHO the Internet
> >> does not work like the Food/Agriculture infrastructure does.
> >>
> >> For example, the new mandates require ISPs to "label" their products
> >> with "nutritional" data including "typical" latency, upload, and
> >> download speeds.   They have until April 2024 to figure it out. I've
> >> never encountered an ISP who could answer such questions - even the ones
> >> I was involved in managing.  Marketing can of course create an answer,
> >> since "typical" is such a vague term.  Figuring out how to attach the
> >> physical label to their service product may be a problem.
> >>
> >> Such labels may not be very helpful to the end user struggling to find
> >> an ISP that delivers the service needed for some interactive use (audio
> >> or video conferencing, gaming, home automation, etc.)
> >>
> >> Performance on the Internet depends on where the two endpoints are, the
> >> physical path to get from one to the other, as well as the hardware,
> >> software, current load, and other aspects of each endpoint, all outside
> >> the ISPs' control or vision.   Since the two endpoints can be on
> >> different ISPs, perhaps requiring one or more additional internediate
> >> ISPs, specifying a "typical" performance from all Points A to all Points
> >> B is even more challenging.
> >>
> >> Switching to the transportation analogy, one might ask your local bus or
> >> rail company what their typical time is to get from one city to
> >> another.   If the two cities involved happen to be on their rail or bus
> >> network, perhaps you can get an answer, but it will still depend on
> >> where the two endpoints are.  If one or both cities are not on their
> >> rail network, the travel time might have to include use of other
> >> "networks" - bus, rental car, airplane, ship, etc.   How long does it
> >> typically take for you to get from any city on the planet to any other
> >> city on the planet?
> >>
> >> IMHO, rules and regulations for the Internet need to reflect how the
> >> Internet actually works.  That's why I suggested a focus on education
> >> for the decision makers.
> >>
> >> Jack Haverty
> >>
> >> _______________________________________________
> >> Nnagain mailing list
> >> Nnagain@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/nnagain
> >
> > _______________________________________________
> > Nnagain mailing list
> > Nnagain@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/nnagain
>
>
>
> --
> Oct 30:
> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
> Dave Täht CSO, LibreQos
>

[-- Attachment #2: Type: text/html, Size: 8605 bytes --]

Re: [NNagain] Internet Education for Non-technorati?

[David Bray, PhD]

[-- Attachment #1.1.1: Type: text/plain, Size: 6897 bytes --]

Here's a label example that is being considered for the "Cyber Trust Mark"
example... it wouldn't just be a boolean mark vs. no mark, it would be
something like this (CMU has helped design it)

[image: cylabs-iot-security-an-1127463569.jpg]

On Wed, Oct 11, 2023 at 2:19 PM David Bray, PhD <david.a.bray@gmail.com>
wrote:

> Are we talking about the one that modelled after the label from CMU (they
> showed some prototypes, there would be about 10-15 pieces of information on
> the label followed by a QR code to get the rest), here's a link - and the
> concerns I have apply to this:
>
>
> https://news.pantheon.cmu.edu/stories/archives/2023/july/cylab-presents-at-white-houses-launch-of-new-iot-cybersecurity-labeling-system
>
>
> https://www.securityindustry.org/2023/09/12/the-fccs-u-s-cyber-trust-mark-proposal-what-it-means-for-the-security-industry/
>
> On Wed, Oct 11, 2023 at 2:06 PM Dave Taht <dave.taht@gmail.com> wrote:
>
>> I think y'all are conflating two different labels here. The nutrition
>> label was one effort, now being deploye, the other is cybersecurity,
>> now being discussed.
>>
>> On the nutrition front...
>> We successfully fought against "packet loss" being included on the
>> nutrition label, but as ghu is my witness, I have no idea if a formal
>> method for declaring "typical latency" was ever formally derived.
>>
>>
>> https://www.fcc.gov/document/fcc-requires-broadband-providers-display-labels-help-consumers
>>
>> On Wed, Oct 11, 2023 at 10:39 AM David Bray, PhD via Nnagain
>> <nnagain@lists.bufferbloat.net> wrote:
>> >
>> > I was at a closed-door event discussing these labels about two weeks
>> ago (right before the potential government shutdown/temporarily averted for
>> now) - and it was non-attribution, so I can only describe my comments:
>> >
>> > (1) the labels risk missing the reality that the Internet and
>> cybersecurity are not steady state, which begs the question how will they
>> be updated
>> > (2) the labels say nothing about how - even if the company promises to
>> keep your data private and secure - how good their security practices are
>> internal to the company? Or what if the company is bought in 5 years?
>> > (3) they use QR-codes to provide additional info, yet we know QR-codes
>> can be sent to bad links so what if someone replaces a label with a bad
>> link such that the label itself becomes an exploit?
>> >
>> > I think the biggest risks is these we be rolled out, some exploit will
>> occur that the label didn't consider, consumers will be angry they weren't
>> "protected" and now we are even in worse shape because the public's trust
>> has gone further down hill, they angry at the government, and the private
>> sector feels like the time and energy they spent on the labels was for
>> naught?
>> >
>> > There's also the concern about how do startups roll-out such a label
>> for their tech in the early iteration phase? How do they afford to do the
>> extra work for the label vs. a big company (does this become a regulatory
>> moat?)
>> >
>> > And let's say we have these labels. Will only consumers with the money
>> to purchase the more expensive equipment that has more privacy and security
>> features buy that one - leaving those who cannot afford privacy and
>> security bad alternatives?
>> >
>> > On Wed, Oct 11, 2023 at 1:31 PM Jack Haverty via Nnagain <
>> nnagain@lists.bufferbloat.net> wrote:
>> >>
>> >> A few days ago I made some comments about the idea of "educating" the
>> >> lawyers, politicians, and other smart, but not necessarily technically
>> >> adept, decision makers.  Today I saw a news story about a recent FCC
>> >> action, to mandate "nutrition labels" on Internet services offered by
>> ISPs:
>> >>
>> >>
>> https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/
>> >>
>> >> This struck me as anecdotal, but a good example of the need for
>> >> education.  Although it's tempting and natural to look at existing
>> >> infrastructures as models for regulating a new one, IMHO the Internet
>> >> does not work like the Food/Agriculture infrastructure does.
>> >>
>> >> For example, the new mandates require ISPs to "label" their products
>> >> with "nutritional" data including "typical" latency, upload, and
>> >> download speeds.   They have until April 2024 to figure it out. I've
>> >> never encountered an ISP who could answer such questions - even the
>> ones
>> >> I was involved in managing.  Marketing can of course create an answer,
>> >> since "typical" is such a vague term.  Figuring out how to attach the
>> >> physical label to their service product may be a problem.
>> >>
>> >> Such labels may not be very helpful to the end user struggling to find
>> >> an ISP that delivers the service needed for some interactive use (audio
>> >> or video conferencing, gaming, home automation, etc.)
>> >>
>> >> Performance on the Internet depends on where the two endpoints are, the
>> >> physical path to get from one to the other, as well as the hardware,
>> >> software, current load, and other aspects of each endpoint, all outside
>> >> the ISPs' control or vision.   Since the two endpoints can be on
>> >> different ISPs, perhaps requiring one or more additional internediate
>> >> ISPs, specifying a "typical" performance from all Points A to all
>> Points
>> >> B is even more challenging.
>> >>
>> >> Switching to the transportation analogy, one might ask your local bus
>> or
>> >> rail company what their typical time is to get from one city to
>> >> another.   If the two cities involved happen to be on their rail or bus
>> >> network, perhaps you can get an answer, but it will still depend on
>> >> where the two endpoints are.  If one or both cities are not on their
>> >> rail network, the travel time might have to include use of other
>> >> "networks" - bus, rental car, airplane, ship, etc.   How long does it
>> >> typically take for you to get from any city on the planet to any other
>> >> city on the planet?
>> >>
>> >> IMHO, rules and regulations for the Internet need to reflect how the
>> >> Internet actually works.  That's why I suggested a focus on education
>> >> for the decision makers.
>> >>
>> >> Jack Haverty
>> >>
>> >> _______________________________________________
>> >> Nnagain mailing list
>> >> Nnagain@lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/nnagain
>> >
>> > _______________________________________________
>> > Nnagain mailing list
>> > Nnagain@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/nnagain
>>
>>
>>
>> --
>> Oct 30:
>> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
>> Dave Täht CSO, LibreQos
>>
>

[-- Attachment #1.1.2: Type: text/html, Size: 9400 bytes --]

[-- Attachment #1.2: cylabs-iot-security-an-1127463569.jpg --]
[-- Type: image/jpeg, Size: 234287 bytes --]

[-- Attachment #2: cylabs-iot-security-an-1127463569.jpg --]
[-- Type: image/jpeg, Size: 234287 bytes --]

Re: [NNagain] Internet Education for Non-technorati?

[Sebastian Moeller]

HI Dave,


> On Oct 11, 2023, at 20:06, Dave Taht via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> 
> I think y'all are conflating two different labels here. The nutrition
> label was one effort, now being deploye, the other is cybersecurity,
> now being discussed.
> 
> On the nutrition front...
> We successfully fought against "packet loss" being included on the
> nutrition label,

	[SM] Not wanting to be contrarian, but I consider a number for random packet loss relevant. The Matthis equation allows to predict the maximal achievable TCP rate over a link with random packet loss and so this has clear bearing on a link's utility. I do agree that the TCP packet loss during an actual speedtest is much less interesting, but random packet loss over a quiet link is an important characteristic... I learned this the hard way when my ISP started to route my access link occasionally over a bad router with ~1% random packet loss (I managed to get my ISPs attention and over the course of a few months they managed to isolate and fix the issue, but I never got a post-mortem of what exactly had happened, all I know is that they dragged one of their hardware vendors into the diagnostics).


> but as ghu is my witness, I have no idea if a formal
> method for declaring "typical latency" was ever formally derived.

	[SM] The easiest really is: set up reference servers outside of all eye-ball ISP AS and distribute a measurement client that will measure against those servers... if you want to improve upon this, locate measurement servers into the AS of the most important transit providers and randomly select one for each test (and report the endpoint location as part of the results).

Best Regards
	Sebastian


> 
> https://www.fcc.gov/document/fcc-requires-broadband-providers-display-labels-help-consumers
> 
> On Wed, Oct 11, 2023 at 10:39 AM David Bray, PhD via Nnagain
> <nnagain@lists.bufferbloat.net> wrote:
>> 
>> I was at a closed-door event discussing these labels about two weeks ago (right before the potential government shutdown/temporarily averted for now) - and it was non-attribution, so I can only describe my comments:
>> 
>> (1) the labels risk missing the reality that the Internet and cybersecurity are not steady state, which begs the question how will they be updated
>> (2) the labels say nothing about how - even if the company promises to keep your data private and secure - how good their security practices are internal to the company? Or what if the company is bought in 5 years?
>> (3) they use QR-codes to provide additional info, yet we know QR-codes can be sent to bad links so what if someone replaces a label with a bad link such that the label itself becomes an exploit?
>> 
>> I think the biggest risks is these we be rolled out, some exploit will occur that the label didn't consider, consumers will be angry they weren't "protected" and now we are even in worse shape because the public's trust has gone further down hill, they angry at the government, and the private sector feels like the time and energy they spent on the labels was for naught?
>> 
>> There's also the concern about how do startups roll-out such a label for their tech in the early iteration phase? How do they afford to do the extra work for the label vs. a big company (does this become a regulatory moat?)
>> 
>> And let's say we have these labels. Will only consumers with the money to purchase the more expensive equipment that has more privacy and security features buy that one - leaving those who cannot afford privacy and security bad alternatives?
>> 
>> On Wed, Oct 11, 2023 at 1:31 PM Jack Haverty via Nnagain <nnagain@lists.bufferbloat.net> wrote:
>>> 
>>> A few days ago I made some comments about the idea of "educating" the
>>> lawyers, politicians, and other smart, but not necessarily technically
>>> adept, decision makers.  Today I saw a news story about a recent FCC
>>> action, to mandate "nutrition labels" on Internet services offered by ISPs:
>>> 
>>> https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/
>>> 
>>> This struck me as anecdotal, but a good example of the need for
>>> education.  Although it's tempting and natural to look at existing
>>> infrastructures as models for regulating a new one, IMHO the Internet
>>> does not work like the Food/Agriculture infrastructure does.
>>> 
>>> For example, the new mandates require ISPs to "label" their products
>>> with "nutritional" data including "typical" latency, upload, and
>>> download speeds.   They have until April 2024 to figure it out. I've
>>> never encountered an ISP who could answer such questions - even the ones
>>> I was involved in managing.  Marketing can of course create an answer,
>>> since "typical" is such a vague term.  Figuring out how to attach the
>>> physical label to their service product may be a problem.
>>> 
>>> Such labels may not be very helpful to the end user struggling to find
>>> an ISP that delivers the service needed for some interactive use (audio
>>> or video conferencing, gaming, home automation, etc.)
>>> 
>>> Performance on the Internet depends on where the two endpoints are, the
>>> physical path to get from one to the other, as well as the hardware,
>>> software, current load, and other aspects of each endpoint, all outside
>>> the ISPs' control or vision.   Since the two endpoints can be on
>>> different ISPs, perhaps requiring one or more additional internediate
>>> ISPs, specifying a "typical" performance from all Points A to all Points
>>> B is even more challenging.
>>> 
>>> Switching to the transportation analogy, one might ask your local bus or
>>> rail company what their typical time is to get from one city to
>>> another.   If the two cities involved happen to be on their rail or bus
>>> network, perhaps you can get an answer, but it will still depend on
>>> where the two endpoints are.  If one or both cities are not on their
>>> rail network, the travel time might have to include use of other
>>> "networks" - bus, rental car, airplane, ship, etc.   How long does it
>>> typically take for you to get from any city on the planet to any other
>>> city on the planet?
>>> 
>>> IMHO, rules and regulations for the Internet need to reflect how the
>>> Internet actually works.  That's why I suggested a focus on education
>>> for the decision makers.
>>> 
>>> Jack Haverty
>>> 
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
> 
> 
> 
> -- 
> Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
> Dave Täht CSO, LibreQos
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:

> There's also the concern about how do startups roll-out such a label for
> their tech in the early iteration phase? How do they afford to do the extra
> work for the label vs. a big company (does this become a regulatory moat?)
>
> And let's say we have these labels. Will only consumers with the money to
> purchase the more expensive equipment that has more privacy and security
> features buy that one - leaving those who cannot afford privacy and
> security bad alternatives?

As far as security goes, I would argue that the easy answer is to ship a current 
version of openwrt instead of a forked, ancient version, and get their changes 
submitted upstream (or at least maintained against upstream). It's a different 
paradigm than they are used to, and right now the suppliers tend to also work 
with ancient versions of openwrt, but in all the companies that I have worked 
at, it's proven to be less ongoing work (and far less risk) to keep up with 
current versions than it is to stick with old versions and then do periodic 'big 
jump' upgrades.

it's like car maintinance, it seems easier to ignore your tires, brakes, and oil 
changes, but the minimal cost of maintaining those systems pays off in a big way 
over time

David Lang

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
Nnagain mailing list
Nnagain@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[rjmcmahon]

I agree that sw & firmware upgrades are better than big jumps.

I don't know the numbers but a guess is that a majority of SoCs with 
WiFi radios aren't based on openwrt. I think many on this list use 
openwrt but that may not be representative of the actuals. Also, the 
trend is less sw in a CPU forwarding plane and more hw, one day, linux 
at the CPEs may not be needed at all (if we get to remote radio heads - 
though this is highly speculative.)

 From my experience, sw is defined by the number & frequency of commits, 
and of timeliness to issues more than a version number or compile date. 
So the size and quality of the software staff can be informative.

I'm more interested in mfg node process then the mfg location & date as 
the node process gives an idea if the design is keeping up or not. Chips 
designed in 2012 are woefully behind and consume too much energy and 
generate too much heat. I think Intel provides this information on all 
its chips as an example.

Bob
> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
> 
>> There's also the concern about how do startups roll-out such a label 
>> for
>> their tech in the early iteration phase? How do they afford to do the 
>> extra
>> work for the label vs. a big company (does this become a regulatory 
>> moat?)
>> 
>> And let's say we have these labels. Will only consumers with the money 
>> to
>> purchase the more expensive equipment that has more privacy and 
>> security
>> features buy that one - leaving those who cannot afford privacy and
>> security bad alternatives?
> 
> As far as security goes, I would argue that the easy answer is to ship
> a current version of openwrt instead of a forked, ancient version, and
> get their changes submitted upstream (or at least maintained against
> upstream). It's a different paradigm than they are used to, and right
> now the suppliers tend to also work with ancient versions of openwrt,
> but in all the companies that I have worked at, it's proven to be less
> ongoing work (and far less risk) to keep up with current versions than
> it is to stick with old versions and then do periodic 'big jump'
> upgrades.
> 
> it's like car maintinance, it seems easier to ignore your tires,
> brakes, and oil changes, but the minimal cost of maintaining those
> systems pays off in a big way over time
> 
> David Lang
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
> 
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[David Lang]

On Wed, 11 Oct 2023, rjmcmahon wrote:

> I don't know the numbers but a guess is that a majority of SoCs with WiFi 
> radios aren't based on openwrt.

From what I've seen, the majority of APs out there are based on OpenWRT or one 
of the competing open projects, very few roll their own OS from scratch

> I think many on this list use openwrt but 
> that may not be representative of the actuals. Also, the trend is less sw in 
> a CPU forwarding plane and more hw, one day, linux at the CPEs may not be 
> needed at all (if we get to remote radio heads - though this is highly 
> speculative.)

that is countered by the trend to do more (fancier GUI, media center, etc) The 
vendors all want to differentiate themselves, that's hard to do if it's baked 
into the chips

> From my experience, sw is defined by the number & frequency of commits, and 
> of timeliness to issues more than a version number or compile date. So the 
> size and quality of the software staff can be informative.
>
> I'm more interested in mfg node process then the mfg location & date as the 
> node process gives an idea if the design is keeping up or not. Chips designed 
> in 2012 are woefully behind and consume too much energy and generate too much 
> heat. I think Intel provides this information on all its chips as an example.

I'm far less concerned about the chips than the software. Security holes are far 
more likely in the software than the chips. The chips may limit the max 
performance of the devices, but the focus of this is on the security, not the 
throughput or the power efficiency (I don't mind that extra info, but what makes 
some device unsafe to use isn't the age of the chips, but the age of the 
software)

David Lang

> Bob
>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>> 
>>> There's also the concern about how do startups roll-out such a label for
>>> their tech in the early iteration phase? How do they afford to do the 
>>> extra
>>> work for the label vs. a big company (does this become a regulatory moat?)
>>> 
>>> And let's say we have these labels. Will only consumers with the money to
>>> purchase the more expensive equipment that has more privacy and security
>>> features buy that one - leaving those who cannot afford privacy and
>>> security bad alternatives?
>> 
>> As far as security goes, I would argue that the easy answer is to ship
>> a current version of openwrt instead of a forked, ancient version, and
>> get their changes submitted upstream (or at least maintained against
>> upstream). It's a different paradigm than they are used to, and right
>> now the suppliers tend to also work with ancient versions of openwrt,
>> but in all the companies that I have worked at, it's proven to be less
>> ongoing work (and far less risk) to keep up with current versions than
>> it is to stick with old versions and then do periodic 'big jump'
>> upgrades.
>> 
>> it's like car maintinance, it seems easier to ignore your tires,
>> brakes, and oil changes, but the minimal cost of maintaining those
>> systems pays off in a big way over time
>> 
>> David Lang
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>

Re: [NNagain] Internet Education for Non-technorati?

[Robert McMahon]

[-- Attachment #1: Type: text/plain, Size: 5075 bytes --]

Hi David,

The vendors I know don't roll their own os code either. The make their own release still mostly based from Linux and they aren't tied to the openwrt release process.

I think GUIs on CPEs are the wrong direction. Consumer network equipment does best when it's plug and play. Consumers don't have all the skills needed to manage an in home packet network that includes wifi.

I recently fixed a home network for my inlaws. It's a combo of structured wire and WiFi APs. I purchased the latest equipment from Amazon vs use the ISP provided equipment. I can do this reasonably well because I'm familiar with the chips inside.

The online tech support started with trepidation as he was concerned that the home owner, i.e me, wasn't as skilled as the ISP technicians. He suggested we schedule that but I said we were good to go w/o one.

He asked to speak to my father in law when we were all done. He told him, "You're lucky to have a son in law that know what he's doing. My techs aren't as good, and I really liked working with him too."

I say this not to brag, as many on this list could do the equivalent, but to show that we really need to train lots of technicians on things like RF and structured wiring. Nobody should be "lucky" to get a quality in home network.  We're not lucky to have a flush toilet anymore. This stuff is too important to rely on luck.

Bob

On Oct 11, 2023, 3:58 PM, at 3:58 PM, David Lang <david@lang.hm> wrote:
>On Wed, 11 Oct 2023, rjmcmahon wrote:
>
>> I don't know the numbers but a guess is that a majority of SoCs with
>WiFi
>> radios aren't based on openwrt.
>
From what I've seen, the majority of APs out there are based on OpenWRT
>or one
>of the competing open projects, very few roll their own OS from scratch
>
>> I think many on this list use openwrt but
>> that may not be representative of the actuals. Also, the trend is
>less sw in
>> a CPU forwarding plane and more hw, one day, linux at the CPEs may
>not be
>> needed at all (if we get to remote radio heads - though this is
>highly
>> speculative.)
>
>that is countered by the trend to do more (fancier GUI, media center,
>etc) The
>vendors all want to differentiate themselves, that's hard to do if it's
>baked
>into the chips
>
>> From my experience, sw is defined by the number & frequency of
>commits, and
>> of timeliness to issues more than a version number or compile date.
>So the
>> size and quality of the software staff can be informative.
>>
>> I'm more interested in mfg node process then the mfg location & date
>as the
>> node process gives an idea if the design is keeping up or not. Chips
>designed
>> in 2012 are woefully behind and consume too much energy and generate
>too much
>> heat. I think Intel provides this information on all its chips as an
>example.
>
>I'm far less concerned about the chips than the software. Security
>holes are far
>more likely in the software than the chips. The chips may limit the max
>
>performance of the devices, but the focus of this is on the security,
>not the
>throughput or the power efficiency (I don't mind that extra info, but
>what makes
>some device unsafe to use isn't the age of the chips, but the age of
>the
>software)
>
>David Lang
>
>> Bob
>>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>
>>>> There's also the concern about how do startups roll-out such a
>label for
>>>> their tech in the early iteration phase? How do they afford to do
>the
>>>> extra
>>>> work for the label vs. a big company (does this become a regulatory
>moat?)
>>>>
>>>> And let's say we have these labels. Will only consumers with the
>money to
>>>> purchase the more expensive equipment that has more privacy and
>security
>>>> features buy that one - leaving those who cannot afford privacy and
>>>> security bad alternatives?
>>> 
>>> As far as security goes, I would argue that the easy answer is to
>ship
>>> a current version of openwrt instead of a forked, ancient version,
>and
>>> get their changes submitted upstream (or at least maintained against
>>> upstream). It's a different paradigm than they are used to, and
>right
>>> now the suppliers tend to also work with ancient versions of
>openwrt,
>>> but in all the companies that I have worked at, it's proven to be
>less
>>> ongoing work (and far less risk) to keep up with current versions
>than
>>> it is to stick with old versions and then do periodic 'big jump'
>>> upgrades.
>>>
>>> it's like car maintinance, it seems easier to ignore your tires,
>>> brakes, and oil changes, but the minimal cost of maintaining those
>>> systems pays off in a big way over time
>>>
>>> David Lang
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>>

[-- Attachment #2: Type: text/html, Size: 6367 bytes --]

Re: [NNagain] Internet Education for Non-technorati?

[rjmcmahon]

Sorry, my openwrt information seems to be incorrect and more vendors use 
openwrt then I realized. So, I really don't know the numbers here.

I do agree with the idea that fixes should be pushed to the mainline and 
that incremental upgrades should be standard practice.

Arista's SW VP gave a talk where he said that 80% of their customer 
calls about bugs were already fixed but their customer wasn't following 
an upgrade policy. This approach applies to most any sw based product.

Bob
> Hi David,
> 
> The vendors I know don't roll their own os code either. The make their
> own release still mostly based from Linux and they aren't tied to the
> openwrt release process.
> 
> I think GUIs on CPEs are the wrong direction. Consumer network
> equipment does best when it's plug and play. Consumers don't have all
> the skills needed to manage an in home packet network that includes
> wifi.
> 
> I recently fixed a home network for my inlaws. It's a combo of
> structured wire and WiFi APs. I purchased the latest equipment from
> Amazon vs use the ISP provided equipment. I can do this reasonably
> well because I'm familiar with the chips inside.
> 
> The online tech support started with trepidation as he was concerned
> that the home owner, i.e me, wasn't as skilled as the ISP technicians.
> He suggested we schedule that but I said we were good to go w/o one.
> 
> He asked to speak to my father in law when we were all done. He told
> him, "You're lucky to have a son in law that know what he's doing. My
> techs aren't as good, and I really liked working with him too."
> 
> I say this not to brag, as many on this list could do the equivalent,
> but to show that we really need to train lots of technicians on things
> like RF and structured wiring. Nobody should be "lucky" to get a
> quality in home network.  We're not lucky to have a flush toilet
> anymore. This stuff is too important to rely on luck.
> 
> Bob
> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
> 
>> On Wed, 11 Oct 2023, rjmcmahon wrote:
>> 
>>> I don't know the numbers but a guess is that a majority of SoCs
>>> with WiFi
>>> radios aren't based on openwrt.
>> 
>> From what I've seen, the majority of APs out there are based on
>> OpenWRT or one
>> of the competing open projects, very few roll their own OS from
>> scratch
>> 
>>> I think many on this list use openwrt but
>>> that may not be representative of the actuals. Also, the trend is
>>> less sw in
>>> a CPU forwarding plane and more hw, one day, linux at the CPEs may
>>> not be
>>> needed at all (if we get to remote radio heads - though this is
>>> highly
>>> speculative.)
>> 
>> that is countered by the trend to do more (fancier GUI, media
>> center, etc) The
>> vendors all want to differentiate themselves, that's hard to do if
>> it's baked
>> into the chips
>> 
>>> From my experience, sw is defined by the number & frequency of
>>> commits, and
>>> of timeliness to issues more than a version number or compile
>>> date. So the
>>> size and quality of the software staff can be informative.
>>> 
>>> I'm more interested in mfg node process then the mfg location &
>>> date as the
>>> node process gives an idea if the design is keeping up or not.
>>> Chips designed
>>> in 2012 are woefully behind and consume too much energy and
>>> generate too much
>>> heat. I think Intel provides this information on all its chips as
>>> an example.
>> 
>> I'm far less concerned about the chips than the software. Security
>> holes are far
>> more likely in the software than the chips. The chips may limit the
>> max
>> performance of the devices, but the focus of this is on the
>> security, not the
>> throughput or the power efficiency (I don't mind that extra info,
>> but what makes
>> some device unsafe to use isn't the age of the chips, but the age of
>> the
>> software)
>> 
>> David Lang
>> 
>> Bob
>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>> 
>> There's also the concern about how do startups roll-out such a
>> label for
>> their tech in the early iteration phase? How do they afford to do
>> the
>> extra
>> work for the label vs. a big company (does this become a regulatory
>> moat?)
>> 
>> And let's say we have these labels. Will only consumers with the
>> money to
>> purchase the more expensive equipment that has more privacy and
>> security
>> features buy that one - leaving those who cannot afford privacy and
>> security bad alternatives?
>> 
>> As far as security goes, I would argue that the easy answer is to
>> ship
>> a current version of openwrt instead of a forked, ancient version,
>> and
>> get their changes submitted upstream (or at least maintained against
>> upstream). It's a different paradigm than they are used to, and
>> right
>> now the suppliers tend to also work with ancient versions of
>> openwrt,
>> but in all the companies that I have worked at, it's proven to be
>> less
>> ongoing work (and far less risk) to keep up with current versions
>> than
>> it is to stick with old versions and then do periodic 'big jump'
>> upgrades.
>> 
>> it's like car maintinance, it seems easier to ignore your tires,
>> brakes, and oil changes, but the minimal cost of maintaining those
>> systems pays off in a big way over time
>> 
>> David Lang
>> 
>> -------------------------
>> 
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> -------------------------
>> 
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[David Lang]

On Thu, 12 Oct 2023, rjmcmahon wrote:

> Arista's SW VP gave a talk where he said that 80% of their customer calls 
> about bugs were already fixed but their customer wasn't following an upgrade 
> policy. This approach applies to most any sw based product.

Yes, there is a big "if it ain't broke don't fix it" attitude out there, because 
most software companies don't really care about backwards compatibility (a rant 
of it's own I won't go into here)

But there's a huge difference between "the customer didn't upgrade" and "the 
vendor didn't provide the upgrade". If we are worried about security ratings of 
devices, we need to focus on the latter first.

David Lang

> Bob
>> Hi David,
>> 
>> The vendors I know don't roll their own os code either. The make their
>> own release still mostly based from Linux and they aren't tied to the
>> openwrt release process.
>> 
>> I think GUIs on CPEs are the wrong direction. Consumer network
>> equipment does best when it's plug and play. Consumers don't have all
>> the skills needed to manage an in home packet network that includes
>> wifi.
>> 
>> I recently fixed a home network for my inlaws. It's a combo of
>> structured wire and WiFi APs. I purchased the latest equipment from
>> Amazon vs use the ISP provided equipment. I can do this reasonably
>> well because I'm familiar with the chips inside.
>> 
>> The online tech support started with trepidation as he was concerned
>> that the home owner, i.e me, wasn't as skilled as the ISP technicians.
>> He suggested we schedule that but I said we were good to go w/o one.
>> 
>> He asked to speak to my father in law when we were all done. He told
>> him, "You're lucky to have a son in law that know what he's doing. My
>> techs aren't as good, and I really liked working with him too."
>> 
>> I say this not to brag, as many on this list could do the equivalent,
>> but to show that we really need to train lots of technicians on things
>> like RF and structured wiring. Nobody should be "lucky" to get a
>> quality in home network.  We're not lucky to have a flush toilet
>> anymore. This stuff is too important to rely on luck.
>> 
>> Bob
>> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>> 
>>> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>> 
>>>> I don't know the numbers but a guess is that a majority of SoCs
>>>> with WiFi
>>>> radios aren't based on openwrt.
>>> 
>>> From what I've seen, the majority of APs out there are based on
>>> OpenWRT or one
>>> of the competing open projects, very few roll their own OS from
>>> scratch
>>> 
>>>> I think many on this list use openwrt but
>>>> that may not be representative of the actuals. Also, the trend is
>>>> less sw in
>>>> a CPU forwarding plane and more hw, one day, linux at the CPEs may
>>>> not be
>>>> needed at all (if we get to remote radio heads - though this is
>>>> highly
>>>> speculative.)
>>> 
>>> that is countered by the trend to do more (fancier GUI, media
>>> center, etc) The
>>> vendors all want to differentiate themselves, that's hard to do if
>>> it's baked
>>> into the chips
>>> 
>>>> From my experience, sw is defined by the number & frequency of
>>>> commits, and
>>>> of timeliness to issues more than a version number or compile
>>>> date. So the
>>>> size and quality of the software staff can be informative.
>>>> 
>>>> I'm more interested in mfg node process then the mfg location &
>>>> date as the
>>>> node process gives an idea if the design is keeping up or not.
>>>> Chips designed
>>>> in 2012 are woefully behind and consume too much energy and
>>>> generate too much
>>>> heat. I think Intel provides this information on all its chips as
>>>> an example.
>>> 
>>> I'm far less concerned about the chips than the software. Security
>>> holes are far
>>> more likely in the software than the chips. The chips may limit the
>>> max
>>> performance of the devices, but the focus of this is on the
>>> security, not the
>>> throughput or the power efficiency (I don't mind that extra info,
>>> but what makes
>>> some device unsafe to use isn't the age of the chips, but the age of
>>> the
>>> software)
>>> 
>>> David Lang
>>> 
>>> Bob
>>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>> 
>>> There's also the concern about how do startups roll-out such a
>>> label for
>>> their tech in the early iteration phase? How do they afford to do
>>> the
>>> extra
>>> work for the label vs. a big company (does this become a regulatory
>>> moat?)
>>> 
>>> And let's say we have these labels. Will only consumers with the
>>> money to
>>> purchase the more expensive equipment that has more privacy and
>>> security
>>> features buy that one - leaving those who cannot afford privacy and
>>> security bad alternatives?
>>> 
>>> As far as security goes, I would argue that the easy answer is to
>>> ship
>>> a current version of openwrt instead of a forked, ancient version,
>>> and
>>> get their changes submitted upstream (or at least maintained against
>>> upstream). It's a different paradigm than they are used to, and
>>> right
>>> now the suppliers tend to also work with ancient versions of
>>> openwrt,
>>> but in all the companies that I have worked at, it's proven to be
>>> less
>>> ongoing work (and far less risk) to keep up with current versions
>>> than
>>> it is to stick with old versions and then do periodic 'big jump'
>>> upgrades.
>>> 
>>> it's like car maintinance, it seems easier to ignore your tires,
>>> brakes, and oil changes, but the minimal cost of maintaining those
>>> systems pays off in a big way over time
>>> 
>>> David Lang
>>> 
>>> -------------------------
>>> 
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>>> 
>>> -------------------------
>>> 
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>

Re: [NNagain] Internet Education for Non-technorati?

[Dave Taht]

On Thu, Oct 12, 2023 at 9:04 AM rjmcmahon via Nnagain
<nnagain@lists.bufferbloat.net> wrote:
>
> Sorry, my openwrt information seems to be incorrect and more vendors use
> openwrt then I realized. So, I really don't know the numbers here.

There are not a lot of choices in the market. On the high end, like
eero, we are seeing Debian derived systems, also some chromeOS
devices. Lower end there is "buildroot", and forked openwrts like
Meraki.

So the whole home router and cpe market has some, usually obsolete,
hacked up, and unmaintained version of openwrt at its heart, on
everything from SFPs to the routers and a lot of iOt, despite many
advancements and security patches in the main build.

It would be my earnest hope, with a clear upgrade path, downstream
manufacturers would release within a few months of the main OpenWrt
releases, or even at the same time, having worked with their customers
through the 6 month release candidate cycle. Microsoft accomplishes
this, at least.

https://www.reddit.com/r/openwrt/comments/175z8t9/imminent_release_of_openwrt_2305/

> I do agree with the idea that fixes should be pushed to the mainline and
> that incremental upgrades should be standard practice.

+1000

> Arista's SW VP gave a talk where he said that 80% of their customer
> calls about bugs were already fixed but their customer wasn't following
> an upgrade policy. This approach applies to most any sw based product.

+100

>
> Bob
> > Hi David,
> >
> > The vendors I know don't roll their own os code either. The make their
> > own release still mostly based from Linux and they aren't tied to the
> > openwrt release process.
> >
> > I think GUIs on CPEs are the wrong direction. Consumer network
> > equipment does best when it's plug and play. Consumers don't have all
> > the skills needed to manage an in home packet network that includes
> > wifi.
> >
> > I recently fixed a home network for my inlaws. It's a combo of
> > structured wire and WiFi APs. I purchased the latest equipment from
> > Amazon vs use the ISP provided equipment. I can do this reasonably
> > well because I'm familiar with the chips inside.
> >
> > The online tech support started with trepidation as he was concerned
> > that the home owner, i.e me, wasn't as skilled as the ISP technicians.
> > He suggested we schedule that but I said we were good to go w/o one.
> >
> > He asked to speak to my father in law when we were all done. He told
> > him, "You're lucky to have a son in law that know what he's doing. My
> > techs aren't as good, and I really liked working with him too."
> >
> > I say this not to brag, as many on this list could do the equivalent,
> > but to show that we really need to train lots of technicians on things
> > like RF and structured wiring. Nobody should be "lucky" to get a
> > quality in home network.  We're not lucky to have a flush toilet
> > anymore. This stuff is too important to rely on luck.
> >
> > Bob
> > On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
> >
> >> On Wed, 11 Oct 2023, rjmcmahon wrote:
> >>
> >>> I don't know the numbers but a guess is that a majority of SoCs
> >>> with WiFi
> >>> radios aren't based on openwrt.
> >>
> >> From what I've seen, the majority of APs out there are based on
> >> OpenWRT or one
> >> of the competing open projects, very few roll their own OS from
> >> scratch
> >>
> >>> I think many on this list use openwrt but
> >>> that may not be representative of the actuals. Also, the trend is
> >>> less sw in
> >>> a CPU forwarding plane and more hw, one day, linux at the CPEs may
> >>> not be
> >>> needed at all (if we get to remote radio heads - though this is
> >>> highly
> >>> speculative.)
> >>
> >> that is countered by the trend to do more (fancier GUI, media
> >> center, etc) The
> >> vendors all want to differentiate themselves, that's hard to do if
> >> it's baked
> >> into the chips
> >>
> >>> From my experience, sw is defined by the number & frequency of
> >>> commits, and
> >>> of timeliness to issues more than a version number or compile
> >>> date. So the
> >>> size and quality of the software staff can be informative.
> >>>
> >>> I'm more interested in mfg node process then the mfg location &
> >>> date as the
> >>> node process gives an idea if the design is keeping up or not.
> >>> Chips designed
> >>> in 2012 are woefully behind and consume too much energy and
> >>> generate too much
> >>> heat. I think Intel provides this information on all its chips as
> >>> an example.
> >>
> >> I'm far less concerned about the chips than the software. Security
> >> holes are far
> >> more likely in the software than the chips. The chips may limit the
> >> max
> >> performance of the devices, but the focus of this is on the
> >> security, not the
> >> throughput or the power efficiency (I don't mind that extra info,
> >> but what makes
> >> some device unsafe to use isn't the age of the chips, but the age of
> >> the
> >> software)
> >>
> >> David Lang
> >>
> >> Bob
> >> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
> >>
> >> There's also the concern about how do startups roll-out such a
> >> label for
> >> their tech in the early iteration phase? How do they afford to do
> >> the
> >> extra
> >> work for the label vs. a big company (does this become a regulatory
> >> moat?)
> >>
> >> And let's say we have these labels. Will only consumers with the
> >> money to
> >> purchase the more expensive equipment that has more privacy and
> >> security
> >> features buy that one - leaving those who cannot afford privacy and
> >> security bad alternatives?
> >>
> >> As far as security goes, I would argue that the easy answer is to
> >> ship
> >> a current version of openwrt instead of a forked, ancient version,
> >> and
> >> get their changes submitted upstream (or at least maintained against
> >> upstream). It's a different paradigm than they are used to, and
> >> right
> >> now the suppliers tend to also work with ancient versions of
> >> openwrt,
> >> but in all the companies that I have worked at, it's proven to be
> >> less
> >> ongoing work (and far less risk) to keep up with current versions
> >> than
> >> it is to stick with old versions and then do periodic 'big jump'
> >> upgrades.
> >>
> >> it's like car maintinance, it seems easier to ignore your tires,
> >> brakes, and oil changes, but the minimal cost of maintaining those
> >> systems pays off in a big way over time
> >>
> >> David Lang
> >>
> >> -------------------------
> >>
> >> Nnagain mailing list
> >> Nnagain@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/nnagain
> >>
> >> -------------------------
> >>
> >> Nnagain mailing list
> >> Nnagain@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/nnagain
> > _______________________________________________
> > Nnagain mailing list
> > Nnagain@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/nnagain
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain



-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos

Re: [NNagain] Internet Education for Non-technorati?

[rjmcmahon]

I looked at openwrt packages and iperf 2 is  at version 2.1.3 which is a 
few years old.

The number of CPE/AP systems to test against is quite large. Then 
throwing in versions for backwards compatibility testing adds yet 
another vector. Since it's performance related, statistical techniques 
are required against multiple metrics to measure statistically the same 
or not. Finally with WiFi, one needs to throw in some controlled, 
repeatable RF variability around the d-matrices (range) & h-matrices 
(frequency responses in both phase and amplitudes per the MIMO spatial 
streams.)

I can see why vendors (& system integrators) might be slow to adopt the 
latest if there is not some sort of extensive qualification ahead of 
that adoption.

Bob

PS. Iperf 2 now has 2.5+ million downloads (if sourceforge is to be 
believed.) My wife suggested I write a book titled, "How to create 
software with 2.5M downloads, a zero marginal cost to produce, and get 
paid zero dollars!!" I suspect many openwrt & other programmers could 
add multiple chapters to such a book.

> On Thu, Oct 12, 2023 at 9:04 AM rjmcmahon via Nnagain
> <nnagain@lists.bufferbloat.net> wrote:
>> 
>> Sorry, my openwrt information seems to be incorrect and more vendors 
>> use
>> openwrt then I realized. So, I really don't know the numbers here.
> 
> There are not a lot of choices in the market. On the high end, like
> eero, we are seeing Debian derived systems, also some chromeOS
> devices. Lower end there is "buildroot", and forked openwrts like
> Meraki.
> 
> So the whole home router and cpe market has some, usually obsolete,
> hacked up, and unmaintained version of openwrt at its heart, on
> everything from SFPs to the routers and a lot of iOt, despite many
> advancements and security patches in the main build.
> 
> It would be my earnest hope, with a clear upgrade path, downstream
> manufacturers would release within a few months of the main OpenWrt
> releases, or even at the same time, having worked with their customers
> through the 6 month release candidate cycle. Microsoft accomplishes
> this, at least.
> 
> https://www.reddit.com/r/openwrt/comments/175z8t9/imminent_release_of_openwrt_2305/
> 
>> I do agree with the idea that fixes should be pushed to the mainline 
>> and
>> that incremental upgrades should be standard practice.
> 
> +1000
> 
>> Arista's SW VP gave a talk where he said that 80% of their customer
>> calls about bugs were already fixed but their customer wasn't 
>> following
>> an upgrade policy. This approach applies to most any sw based product.
> 
> +100
> 
>> 
>> Bob
>> > Hi David,
>> >
>> > The vendors I know don't roll their own os code either. The make their
>> > own release still mostly based from Linux and they aren't tied to the
>> > openwrt release process.
>> >
>> > I think GUIs on CPEs are the wrong direction. Consumer network
>> > equipment does best when it's plug and play. Consumers don't have all
>> > the skills needed to manage an in home packet network that includes
>> > wifi.
>> >
>> > I recently fixed a home network for my inlaws. It's a combo of
>> > structured wire and WiFi APs. I purchased the latest equipment from
>> > Amazon vs use the ISP provided equipment. I can do this reasonably
>> > well because I'm familiar with the chips inside.
>> >
>> > The online tech support started with trepidation as he was concerned
>> > that the home owner, i.e me, wasn't as skilled as the ISP technicians.
>> > He suggested we schedule that but I said we were good to go w/o one.
>> >
>> > He asked to speak to my father in law when we were all done. He told
>> > him, "You're lucky to have a son in law that know what he's doing. My
>> > techs aren't as good, and I really liked working with him too."
>> >
>> > I say this not to brag, as many on this list could do the equivalent,
>> > but to show that we really need to train lots of technicians on things
>> > like RF and structured wiring. Nobody should be "lucky" to get a
>> > quality in home network.  We're not lucky to have a flush toilet
>> > anymore. This stuff is too important to rely on luck.
>> >
>> > Bob
>> > On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>> >
>> >> On Wed, 11 Oct 2023, rjmcmahon wrote:
>> >>
>> >>> I don't know the numbers but a guess is that a majority of SoCs
>> >>> with WiFi
>> >>> radios aren't based on openwrt.
>> >>
>> >> From what I've seen, the majority of APs out there are based on
>> >> OpenWRT or one
>> >> of the competing open projects, very few roll their own OS from
>> >> scratch
>> >>
>> >>> I think many on this list use openwrt but
>> >>> that may not be representative of the actuals. Also, the trend is
>> >>> less sw in
>> >>> a CPU forwarding plane and more hw, one day, linux at the CPEs may
>> >>> not be
>> >>> needed at all (if we get to remote radio heads - though this is
>> >>> highly
>> >>> speculative.)Peregrine - 112G PAM4
>> >>
>> >> that is countered by the trend to do more (fancier GUI, media
>> >> center, etc) The
>> >> vendors all want to differentiate themselves, that's hard to do if
>> >> it's baked
>> >> into the chips
>> >>
>> >>> From my experience, sw is defined by the number & frequency of
>> >>> commits, and
>> >>> of timeliness to issues more than a version number or compile
>> >>> date. So the
>> >>> size and quality of the software staff can be informative.
>> >>>
>> >>> I'm more interested in mfg node process then the mfg location &
>> >>> date as the
>> >>> node process gives an idea if the design is keeping up or not.
>> >>> Chips designed
>> >>> in 2012 are woefully behind and consume too much energy and
>> >>> generate too much
>> >>> heat. I think Intel provides this information on all its chips as
>> >>> an example.
>> >>
>> >> I'm far less concerned about the chips than the software. Security
>> >> holes are far
>> >> more likely in the software than the chips. The chips may limit the
>> >> max
>> >> performance of the devices, but the focus of this is on the
>> >> security, not the
>> >> throughput or the power efficiency (I don't mind that extra info,
>> >> but what makes
>> >> some device unsafe to use isn't the age of the chips, but the age of
>> >> the
>> >> software)
>> >>
>> >> David Lang
>> >>
>> >> Bob
>> >> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>> >>
>> >> There's also the concern about how do startups roll-out such a
>> >> label for
>> >> their tech in the early iteration phase? How do they afford to do
>> >> the
>> >> extra
>> >> work for the label vs. a big company (does this become a regulatory
>> >> moat?)
>> >>
>> >> And let's say we have these labels. Will only consumers with the
>> >> money to
>> >> purchase the more expensive equipment that has more privacy and
>> >> security
>> >> features buy that one - leaving those who cannot afford privacy and
>> >> security bad alternatives?
>> >>
>> >> As far as security goes, I would argue that the easy answer is to
>> >> ship
>> >> a current version of openwrt instead of a forked, ancient version,
>> >> and
>> >> get their changes submitted upstream (or at least maintained against
>> >> upstream). It's a different paradigm than they are used to, and
>> >> right
>> >> now the suppliers tend to also work with ancient versions of
>> >> openwrt,
>> >> but in all the companies that I have worked at, it's proven to be
>> >> less
>> >> ongoing work (and far less risk) to keep up with current versions
>> >> than
>> >> it is to stick with old versions and then do periodic 'big jump'
>> >> upgrades.
>> >>
>> >> it's like car maintinance, it seems easier to ignore your tires,
>> >> brakes, and oil changes, but the minimal cost of maintaining those
>> >> systems pays off in a big way over time
>> >>
>> >> David Lang
>> >>
>> >> -------------------------
>> >>
>> >> Nnagain mailing list
>> >> Nnagain@lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/nnagain
>> >>
>> >> -------------------------
>> >>
>> >> Nnagain mailing list
>> >> Nnagain@lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/nnagain
>> > _______________________________________________
>> > Nnagain mailing list
>> > Nnagain@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/nnagain
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 9632 bytes --]

On Thu, 12 Oct 2023, rjmcmahon via Nnagain wrote:

> I looked at openwrt packages and iperf 2 is  at version 2.1.3 which is a 
> few years old.
>
> The number of CPE/AP systems to test against is quite large. Then 
> throwing in versions for backwards compatibility testing adds yet 
> another vector.

for the market as a whole, yes, it's a hard problem. But for an individual 
manfacturer, they only have to work with their equipment, not all the others. 
The RF side isn't changing from release to release (and usually the firmware for 
the Wifi isn't changing), so that eliminates a lot of the work. They need to do 
more smoke testing of new releases than a full regression/performance test. Some 
incompatibility creeping in is the most likely problem, not a subtle performance 
issue.

For the Scale conference, we have a Pi tied to a couple relays hooked to the 
motherboard of the router we use and it's tied in to our github repo, so every 
PR gets auto-flashed to the router and simple checks done. Things like this 
should be easy to setup and will catch most issues.

David Lang

> Since it's performance related, statistical techniques 
> are required against multiple metrics to measure statistically the same 
> or not. Finally with WiFi, one needs to throw in some controlled, 
> repeatable RF variability around the d-matrices (range) & h-matrices 
> (frequency responses in both phase and amplitudes per the MIMO spatial 
> streams.)
>
> I can see why vendors (& system integrators) might be slow to adopt the 
> latest if there is not some sort of extensive qualification ahead of 
> that adoption.
>
> Bob
>
> PS. Iperf 2 now has 2.5+ million downloads (if sourceforge is to be 
> believed.) My wife suggested I write a book titled, "How to create 
> software with 2.5M downloads, a zero marginal cost to produce, and get 
> paid zero dollars!!" I suspect many openwrt & other programmers could 
> add multiple chapters to such a book.
>
>> On Thu, Oct 12, 2023 at 9:04 AM rjmcmahon via Nnagain
>> <nnagain@lists.bufferbloat.net> wrote:
>>> 
>>> Sorry, my openwrt information seems to be incorrect and more vendors 
>>> use
>>> openwrt then I realized. So, I really don't know the numbers here.
>> 
>> There are not a lot of choices in the market. On the high end, like
>> eero, we are seeing Debian derived systems, also some chromeOS
>> devices. Lower end there is "buildroot", and forked openwrts like
>> Meraki.
>> 
>> So the whole home router and cpe market has some, usually obsolete,
>> hacked up, and unmaintained version of openwrt at its heart, on
>> everything from SFPs to the routers and a lot of iOt, despite many
>> advancements and security patches in the main build.
>> 
>> It would be my earnest hope, with a clear upgrade path, downstream
>> manufacturers would release within a few months of the main OpenWrt
>> releases, or even at the same time, having worked with their customers
>> through the 6 month release candidate cycle. Microsoft accomplishes
>> this, at least.
>> 
>> 
> https://www.reddit.com/r/openwrt/comments/175z8t9/imminent_release_of_openwrt_2305/
>> 
>>> I do agree with the idea that fixes should be pushed to the mainline 
>>> and
>>> that incremental upgrades should be standard practice.
>> 
>> +1000
>> 
>>> Arista's SW VP gave a talk where he said that 80% of their customer
>>> calls about bugs were already fixed but their customer wasn't 
>>> following
>>> an upgrade policy. This approach applies to most any sw based product.
>> 
>> +100
>> 
>>> 
>>> Bob
>>> > Hi David,
>>> >
>>> > The vendors I know don't roll their own os code either. The make their
>>> > own release still mostly based from Linux and they aren't tied to the
>>> > openwrt release process.
>>> >
>>> > I think GUIs on CPEs are the wrong direction. Consumer network
>>> > equipment does best when it's plug and play. Consumers don't have all
>>> > the skills needed to manage an in home packet network that includes
>>> > wifi.
>>> >
>>> > I recently fixed a home network for my inlaws. It's a combo of
>>> > structured wire and WiFi APs. I purchased the latest equipment from
>>> > Amazon vs use the ISP provided equipment. I can do this reasonably
>>> > well because I'm familiar with the chips inside.
>>> >
>>> > The online tech support started with trepidation as he was concerned
>>> > that the home owner, i.e me, wasn't as skilled as the ISP technicians.
>>> > He suggested we schedule that but I said we were good to go w/o one.
>>> >
>>> > He asked to speak to my father in law when we were all done. He told
>>> > him, "You're lucky to have a son in law that know what he's doing. My
>>> > techs aren't as good, and I really liked working with him too."
>>> >
>>> > I say this not to brag, as many on this list could do the equivalent,
>>> > but to show that we really need to train lots of technicians on things
>>> > like RF and structured wiring. Nobody should be "lucky" to get a
>>> > quality in home network.  We're not lucky to have a flush toilet
>>> > anymore. This stuff is too important to rely on luck.
>>> >
>>> > Bob
>>> > On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>> >
>>> >> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>> >>
>>> >>> I don't know the numbers but a guess is that a majority of SoCs
>>> >>> with WiFi
>>> >>> radios aren't based on openwrt.
>>> >>
>>> >> From what I've seen, the majority of APs out there are based on
>>> >> OpenWRT or one
>>> >> of the competing open projects, very few roll their own OS from
>>> >> scratch
>>> >>
>>> >>> I think many on this list use openwrt but
>>> >>> that may not be representative of the actuals. Also, the trend is
>>> >>> less sw in
>>> >>> a CPU forwarding plane and more hw, one day, linux at the CPEs may
>>> >>> not be
>>> >>> needed at all (if we get to remote radio heads - though this is
>>> >>> highly
>>> >>> speculative.)Peregrine - 112G PAM4
>>> >>
>>> >> that is countered by the trend to do more (fancier GUI, media
>>> >> center, etc) The
>>> >> vendors all want to differentiate themselves, that's hard to do if
>>> >> it's baked
>>> >> into the chips
>>> >>
>>> >>> From my experience, sw is defined by the number & frequency of
>>> >>> commits, and
>>> >>> of timeliness to issues more than a version number or compile
>>> >>> date. So the
>>> >>> size and quality of the software staff can be informative.
>>> >>>
>>> >>> I'm more interested in mfg node process then the mfg location &
>>> >>> date as the
>>> >>> node process gives an idea if the design is keeping up or not.
>>> >>> Chips designed
>>> >>> in 2012 are woefully behind and consume too much energy and
>>> >>> generate too much
>>> >>> heat. I think Intel provides this information on all its chips as
>>> >>> an example.
>>> >>
>>> >> I'm far less concerned about the chips than the software. Security
>>> >> holes are far
>>> >> more likely in the software than the chips. The chips may limit the
>>> >> max
>>> >> performance of the devices, but the focus of this is on the
>>> >> security, not the
>>> >> throughput or the power efficiency (I don't mind that extra info,
>>> >> but what makes
>>> >> some device unsafe to use isn't the age of the chips, but the age of
>>> >> the
>>> >> software)
>>> >>
>>> >> David Lang
>>> >>
>>> >> Bob
>>> >> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>> >>
>>> >> There's also the concern about how do startups roll-out such a
>>> >> label for
>>> >> their tech in the early iteration phase? How do they afford to do
>>> >> the
>>> >> extra
>>> >> work for the label vs. a big company (does this become a regulatory
>>> >> moat?)
>>> >>
>>> >> And let's say we have these labels. Will only consumers with the
>>> >> money to
>>> >> purchase the more expensive equipment that has more privacy and
>>> >> security
>>> >> features buy that one - leaving those who cannot afford privacy and
>>> >> security bad alternatives?
>>> >>
>>> >> As far as security goes, I would argue that the easy answer is to
>>> >> ship
>>> >> a current version of openwrt instead of a forked, ancient version,
>>> >> and
>>> >> get their changes submitted upstream (or at least maintained against
>>> >> upstream). It's a different paradigm than they are used to, and
>>> >> right
>>> >> now the suppliers tend to also work with ancient versions of
>>> >> openwrt,
>>> >> but in all the companies that I have worked at, it's proven to be
>>> >> less
>>> >> ongoing work (and far less risk) to keep up with current versions
>>> >> than
>>> >> it is to stick with old versions and then do periodic 'big jump'
>>> >> upgrades.
>>> >>
>>> >> it's like car maintinance, it seems easier to ignore your tires,
>>> >> brakes, and oil changes, but the minimal cost of maintaining those
>>> >> systems pays off in a big way over time
>>> >>
>>> >> David Lang
>>> >>
>>> >> -------------------------
>>> >>
>>> >> Nnagain mailing list
>>> >> Nnagain@lists.bufferbloat.net
>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>> >>
>>> >> -------------------------
>>> >>
>>> >> Nnagain mailing list
>>> >> Nnagain@lists.bufferbloat.net
>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>> > _______________________________________________
>>> > Nnagain mailing list
>>> > Nnagain@lists.bufferbloat.net
>>> > https://lists.bufferbloat.net/listinfo/nnagain
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>

Re: [NNagain] Internet Education for Non-technorati?

[rjmcmahon]

Hi David,

I think we're looking at different parts of the elephant. I perceive 
huge advances in WiFi (phy, dsp, radios, fems, etc.) and residential 
gateway chips of late. Not sure the state of chips used by the openwrt 
folks here, though they may be lagging a bit - not sure.

https://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7

Broadcom’s Wi-Fi 7 ecosystem product portfolio includes the BCM6765, 
BCM47722, and BCM4390.

The BCM6765 is optimized for the residential Wi-Fi access point market. 
Key features include:
...
The BCM47722 is an enterprise access point platform SoC supporting Wi-Fi 
7, Bluetooth Low Energy, and 802.15.4 protocols. Key features include:
...
The BCM4390 is a highly-integrated Wi-Fi 7 and Bluetooth 5 combo chip 
optimized for mobile handset applications. Key features include:
...

Bob
> On Thu, 12 Oct 2023, rjmcmahon via Nnagain wrote:
> 
>> I looked at openwrt packages and iperf 2 is  at version 2.1.3 which is 
>> a few years old.
>> 
>> The number of CPE/AP systems to test against is quite large. Then 
>> throwing in versions for backwards compatibility testing adds yet 
>> another vector.
> 
> for the market as a whole, yes, it's a hard problem. But for an
> individual manfacturer, they only have to work with their equipment,
> not all the others. The RF side isn't changing from release to release
> (and usually the firmware for the Wifi isn't changing), so that
> eliminates a lot of the work. They need to do more smoke testing of
> new releases than a full regression/performance test. Some
> incompatibility creeping in is the most likely problem, not a subtle
> performance issue.
> 
> For the Scale conference, we have a Pi tied to a couple relays hooked
> to the motherboard of the router we use and it's tied in to our github
> repo, so every PR gets auto-flashed to the router and simple checks
> done. Things like this should be easy to setup and will catch most
> issues.
> 
> David Lang
> 
>> Since it's performance related, statistical techniques are required 
>> against multiple metrics to measure statistically the same or not. 
>> Finally with WiFi, one needs to throw in some controlled, repeatable 
>> RF variability around the d-matrices (range) & h-matrices (frequency 
>> responses in both phase and amplitudes per the MIMO spatial streams.)
>> 
>> I can see why vendors (& system integrators) might be slow to adopt 
>> the latest if there is not some sort of extensive qualification ahead 
>> of that adoption.
>> 
>> Bob
>> 
>> PS. Iperf 2 now has 2.5+ million downloads (if sourceforge is to be 
>> believed.) My wife suggested I write a book titled, "How to create 
>> software with 2.5M downloads, a zero marginal cost to produce, and get 
>> paid zero dollars!!" I suspect many openwrt & other programmers could 
>> add multiple chapters to such a book.
>> 
>>> On Thu, Oct 12, 2023 at 9:04 AM rjmcmahon via Nnagain
>>> <nnagain@lists.bufferbloat.net> wrote:
>>>> 
>>>> Sorry, my openwrt information seems to be incorrect and more vendors 
>>>> use
>>>> openwrt then I realized. So, I really don't know the numbers here.
>>> 
>>> There are not a lot of choices in the market. On the high end, like
>>> eero, we are seeing Debian derived systems, also some chromeOS
>>> devices. Lower end there is "buildroot", and forked openwrts like
>>> Meraki.
>>> 
>>> So the whole home router and cpe market has some, usually obsolete,
>>> hacked up, and unmaintained version of openwrt at its heart, on
>>> everything from SFPs to the routers and a lot of iOt, despite many
>>> advancements and security patches in the main build.
>>> 
>>> It would be my earnest hope, with a clear upgrade path, downstream
>>> manufacturers would release within a few months of the main OpenWrt
>>> releases, or even at the same time, having worked with their 
>>> customers
>>> through the 6 month release candidate cycle. Microsoft accomplishes
>>> this, at least.
>>> 
>>> 
>> https://www.reddit.com/r/openwrt/comments/175z8t9/imminent_release_of_openwrt_2305/
>>> 
>>>> I do agree with the idea that fixes should be pushed to the mainline 
>>>> and
>>>> that incremental upgrades should be standard practice.
>>> 
>>> +1000
>>> 
>>>> Arista's SW VP gave a talk where he said that 80% of their customer
>>>> calls about bugs were already fixed but their customer wasn't 
>>>> following
>>>> an upgrade policy. This approach applies to most any sw based 
>>>> product.
>>> 
>>> +100
>>> 
>>>> 
>>>> Bob
>>>> > Hi David,
>>>> >
>>>> > The vendors I know don't roll their own os code either. The make their
>>>> > own release still mostly based from Linux and they aren't tied to the
>>>> > openwrt release process.
>>>> >
>>>> > I think GUIs on CPEs are the wrong direction. Consumer network
>>>> > equipment does best when it's plug and play. Consumers don't have all
>>>> > the skills needed to manage an in home packet network that includes
>>>> > wifi.
>>>> >
>>>> > I recently fixed a home network for my inlaws. It's a combo of
>>>> > structured wire and WiFi APs. I purchased the latest equipment from
>>>> > Amazon vs use the ISP provided equipment. I can do this reasonably
>>>> > well because I'm familiar with the chips inside.
>>>> >
>>>> > The online tech support started with trepidation as he was concerned
>>>> > that the home owner, i.e me, wasn't as skilled as the ISP technicians.
>>>> > He suggested we schedule that but I said we were good to go w/o one.
>>>> >
>>>> > He asked to speak to my father in law when we were all done. He told
>>>> > him, "You're lucky to have a son in law that know what he's doing. My
>>>> > techs aren't as good, and I really liked working with him too."
>>>> >
>>>> > I say this not to brag, as many on this list could do the equivalent,
>>>> > but to show that we really need to train lots of technicians on things
>>>> > like RF and structured wiring. Nobody should be "lucky" to get a
>>>> > quality in home network.  We're not lucky to have a flush toilet
>>>> > anymore. This stuff is too important to rely on luck.
>>>> >
>>>> > Bob
>>>> > On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>> >
>>>> >> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>> >>
>>>> >>> I don't know the numbers but a guess is that a majority of SoCs
>>>> >>> with WiFi
>>>> >>> radios aren't based on openwrt.
>>>> >>
>>>> >> From what I've seen, the majority of APs out there are based on
>>>> >> OpenWRT or one
>>>> >> of the competing open projects, very few roll their own OS from
>>>> >> scratch
>>>> >>
>>>> >>> I think many on this list use openwrt but
>>>> >>> that may not be representative of the actuals. Also, the trend is
>>>> >>> less sw in
>>>> >>> a CPU forwarding plane and more hw, one day, linux at the CPEs mayhttps://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
>>>> >>> not be
>>>> >>> needed at all (if we get to remote radio heads - though this is
>>>> >>> highly
>>>> >>> speculative.)Peregrine - 112G PAM4
>>>> >>
>>>> >> that is countered by the trend to do more (fancier GUI, media
>>>> >> center, etc) The
>>>> >> vendors all want to differentiate themselves, that's hard to do if
>>>> >> it's baked
>>>> >> into the chips
>>>> >>
>>>> >>> From my experience, sw is defined by the number & frequency of
>>>> >>> commits, and
>>>> >>> of timeliness to issues more than a version number or compile
>>>> >>> date. So the
>>>> >>> size and quality of the software staff can be informative.
>>>> >>>
>>>> >>> I'm more interested in mfg node process then the mfg location &
>>>> >>> date as the
>>>> >>> node process gives an idea if the design is keeping up or not.
>>>> >>> Chips designed
>>>> >>> in 2012 are woefully behind and consume too much energy and
>>>> >>> generate too much
>>>> >>> heat. I think Intel provides this information on all its chips as
>>>> >>> an example.
>>>> >>
>>>> >> I'm far less concerned about the chips than the software. Security
>>>> >> holes are far
>>>> >> more likely in the software than the chips. The chips may limit the
>>>> >> max
>>>> >> performance of the devices, but the focus of this is on the
>>>> >> security, not the
>>>> >> throughput or the power efficiency (I don't mind that extra info,
>>>> >> but what makes
>>>> >> some device unsafe to use isn't the age of the chips, but the age of
>>>> >> the
>>>> >> software)
>>>> >>
>>>> >> David Lang
>>>> >>
>>>> >> Bob
>>>> >> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>> >>
>>>> >> There's also the concern about how do startups roll-out such a
>>>> >> label for
>>>> >> their tech in the early iteration phase? How do they afford to do
>>>> >> the
>>>> >> extra
>>>> >> work for the label vs. a big company (does this become a regulatory
>>>> >> moat?)
>>>> >>
>>>> >> And let's say we have these labels. Will only consumers with the
>>>> >> money to
>>>> >> purchase the more expensive equipment that has more privacy and
>>>> >> security
>>>> >> features buy that one - leaving those who cannot afford privacy and
>>>> >> security bad alternatives?
>>>> >>
>>>> >> As far as security goes, I would argue that the easy answer is to
>>>> >> ship
>>>> >> a current version of openwrt instead of a forked, ancient version,
>>>> >> and
>>>> >> get their changes submitted upstream (or at least maintained against
>>>> >> upstream). It's a different paradigm than they are used to, and
>>>> >> right
>>>> >> now the suppliers tend to also work with ancient versions of
>>>> >> openwrt,
>>>> >> but in all the companies that I have worked at, it's proven to be
>>>> >> less
>>>> >> ongoing work (and far less risk) to keep up with current versions
>>>> >> than
>>>> >> it is to stick with old versions and then do periodic 'big jump'
>>>> >> upgrades.
>>>> >>
>>>> >> it's like car maintinance, it seems easier to ignore your tires,
>>>> >> brakes, and oil changes, but the minimal cost of maintaining those
>>>> >> systems pays off in a big way over time
>>>> >>
>>>> >> David Lang
>>>> >>
>>>> >> -------------------------
>>>> >>
>>>> >> Nnagain mailing list
>>>> >> Nnagain@lists.bufferbloat.net
>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>> >>
>>>> >> -------------------------
>>>> >>
>>>> >> Nnagain mailing list
>>>> >> Nnagain@lists.bufferbloat.net
>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>> > _______________________________________________
>>>> > Nnagain mailing list
>>>> > Nnagain@lists.bufferbloat.net
>>>> > https://lists.bufferbloat.net/listinfo/nnagain
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>> 

Re: [NNagain] Internet Education for Non-technorati?

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 11517 bytes --]

On Thu, 12 Oct 2023, rjmcmahon wrote:

> I think we're looking at different parts of the elephant. I perceive huge 
> advances in WiFi (phy, dsp, radios, fems, etc.) and residential gateway chips 
> of late.

My point is that the chips behavior doesn't change when you switch to a newer 
release of openwrt on the same chipset. When you do  a new hardware version, you 
need to do all the testing that was mentioned (and more) but if you are looking 
at updating the opewrt image, you have far less that you need to check.

David Lang

> Not sure the state of chips used by the openwrt folks here, though 
> they may be lagging a bit - not sure.
>
> https://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
>
> Broadcom’s Wi-Fi 7 ecosystem product portfolio includes the BCM6765, 
> BCM47722, and BCM4390.
>
> The BCM6765 is optimized for the residential Wi-Fi access point market. Key 
> features include:
> ...
> The BCM47722 is an enterprise access point platform SoC supporting Wi-Fi 7, 
> Bluetooth Low Energy, and 802.15.4 protocols. Key features include:
> ...
> The BCM4390 is a highly-integrated Wi-Fi 7 and Bluetooth 5 combo chip 
> optimized for mobile handset applications. Key features include:
> ...
>
> Bob
>> On Thu, 12 Oct 2023, rjmcmahon via Nnagain wrote:
>> 
>>> I looked at openwrt packages and iperf 2 is  at version 2.1.3 which is a 
>>> few years old.
>>> 
>>> The number of CPE/AP systems to test against is quite large. Then throwing 
>>> in versions for backwards compatibility testing adds yet another vector.
>> 
>> for the market as a whole, yes, it's a hard problem. But for an
>> individual manfacturer, they only have to work with their equipment,
>> not all the others. The RF side isn't changing from release to release
>> (and usually the firmware for the Wifi isn't changing), so that
>> eliminates a lot of the work. They need to do more smoke testing of
>> new releases than a full regression/performance test. Some
>> incompatibility creeping in is the most likely problem, not a subtle
>> performance issue.
>> 
>> For the Scale conference, we have a Pi tied to a couple relays hooked
>> to the motherboard of the router we use and it's tied in to our github
>> repo, so every PR gets auto-flashed to the router and simple checks
>> done. Things like this should be easy to setup and will catch most
>> issues.
>> 
>> David Lang
>> 
>>> Since it's performance related, statistical techniques are required 
>>> against multiple metrics to measure statistically the same or not. Finally 
>>> with WiFi, one needs to throw in some controlled, repeatable RF 
>>> variability around the d-matrices (range) & h-matrices (frequency 
>>> responses in both phase and amplitudes per the MIMO spatial streams.)
>>> 
>>> I can see why vendors (& system integrators) might be slow to adopt the 
>>> latest if there is not some sort of extensive qualification ahead of that 
>>> adoption.
>>> 
>>> Bob
>>> 
>>> PS. Iperf 2 now has 2.5+ million downloads (if sourceforge is to be 
>>> believed.) My wife suggested I write a book titled, "How to create 
>>> software with 2.5M downloads, a zero marginal cost to produce, and get 
>>> paid zero dollars!!" I suspect many openwrt & other programmers could add 
>>> multiple chapters to such a book.
>>> 
>>>> On Thu, Oct 12, 2023 at 9:04 AM rjmcmahon via Nnagain
>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>> 
>>>>> Sorry, my openwrt information seems to be incorrect and more vendors use
>>>>> openwrt then I realized. So, I really don't know the numbers here.
>>>> 
>>>> There are not a lot of choices in the market. On the high end, like
>>>> eero, we are seeing Debian derived systems, also some chromeOS
>>>> devices. Lower end there is "buildroot", and forked openwrts like
>>>> Meraki.
>>>> 
>>>> So the whole home router and cpe market has some, usually obsolete,
>>>> hacked up, and unmaintained version of openwrt at its heart, on
>>>> everything from SFPs to the routers and a lot of iOt, despite many
>>>> advancements and security patches in the main build.
>>>> 
>>>> It would be my earnest hope, with a clear upgrade path, downstream
>>>> manufacturers would release within a few months of the main OpenWrt
>>>> releases, or even at the same time, having worked with their customers
>>>> through the 6 month release candidate cycle. Microsoft accomplishes
>>>> this, at least.
>>>> 
>>>> 
>>> https://www.reddit.com/r/openwrt/comments/175z8t9/imminent_release_of_openwrt_2305/
>>>> 
>>>>> I do agree with the idea that fixes should be pushed to the mainline and
>>>>> that incremental upgrades should be standard practice.
>>>> 
>>>> +1000
>>>> 
>>>>> Arista's SW VP gave a talk where he said that 80% of their customer
>>>>> calls about bugs were already fixed but their customer wasn't following
>>>>> an upgrade policy. This approach applies to most any sw based product.
>>>> 
>>>> +100
>>>> 
>>>>> 
>>>>> Bob
>>>>> > Hi David,
>>>>> >
>>>>> > The vendors I know don't roll their own os code either. The make their
>>>>> > own release still mostly based from Linux and they aren't tied to the
>>>>> > openwrt release process.
>>>>> >
>>>>> > I think GUIs on CPEs are the wrong direction. Consumer network
>>>>> > equipment does best when it's plug and play. Consumers don't have all
>>>>> > the skills needed to manage an in home packet network that includes
>>>>> > wifi.
>>>>> >
>>>>> > I recently fixed a home network for my inlaws. It's a combo of
>>>>> > structured wire and WiFi APs. I purchased the latest equipment from
>>>>> > Amazon vs use the ISP provided equipment. I can do this reasonably
>>>>> > well because I'm familiar with the chips inside.
>>>>> >
>>>>> > The online tech support started with trepidation as he was concerned
>>>>> > that the home owner, i.e me, wasn't as skilled as the ISP technicians.
>>>>> > He suggested we schedule that but I said we were good to go w/o one.
>>>>> >
>>>>> > He asked to speak to my father in law when we were all done. He told
>>>>> > him, "You're lucky to have a son in law that know what he's doing. My
>>>>> > techs aren't as good, and I really liked working with him too."
>>>>> >
>>>>> > I say this not to brag, as many on this list could do the equivalent,
>>>>> > but to show that we really need to train lots of technicians on things
>>>>> > like RF and structured wiring. Nobody should be "lucky" to get a
>>>>> > quality in home network.  We're not lucky to have a flush toilet
>>>>> > anymore. This stuff is too important to rely on luck.
>>>>> >
>>>>> > Bob
>>>>> > On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>>> >
>>>>> >> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>>> >>
>>>>> >>> I don't know the numbers but a guess is that a majority of SoCs
>>>>> >>> with WiFi
>>>>> >>> radios aren't based on openwrt.
>>>>> >>
>>>>> >> From what I've seen, the majority of APs out there are based on
>>>>> >> OpenWRT or one
>>>>> >> of the competing open projects, very few roll their own OS from
>>>>> >> scratch
>>>>> >>
>>>>> >>> I think many on this list use openwrt but
>>>>> >>> that may not be representative of the actuals. Also, the trend is
>>>>> >>> less sw in
>>>>> >>> a CPU forwarding plane and more hw, one day, linux at the CPEs 
>>>>> mayhttps://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
>>>>> >>> not be
>>>>> >>> needed at all (if we get to remote radio heads - though this is
>>>>> >>> highly
>>>>> >>> speculative.)Peregrine - 112G PAM4
>>>>> >>
>>>>> >> that is countered by the trend to do more (fancier GUI, media
>>>>> >> center, etc) The
>>>>> >> vendors all want to differentiate themselves, that's hard to do if
>>>>> >> it's baked
>>>>> >> into the chips
>>>>> >>
>>>>> >>> From my experience, sw is defined by the number & frequency of
>>>>> >>> commits, and
>>>>> >>> of timeliness to issues more than a version number or compile
>>>>> >>> date. So the
>>>>> >>> size and quality of the software staff can be informative.
>>>>> >>>
>>>>> >>> I'm more interested in mfg node process then the mfg location &
>>>>> >>> date as the
>>>>> >>> node process gives an idea if the design is keeping up or not.
>>>>> >>> Chips designed
>>>>> >>> in 2012 are woefully behind and consume too much energy and
>>>>> >>> generate too much
>>>>> >>> heat. I think Intel provides this information on all its chips as
>>>>> >>> an example.
>>>>> >>
>>>>> >> I'm far less concerned about the chips than the software. Security
>>>>> >> holes are far
>>>>> >> more likely in the software than the chips. The chips may limit the
>>>>> >> max
>>>>> >> performance of the devices, but the focus of this is on the
>>>>> >> security, not the
>>>>> >> throughput or the power efficiency (I don't mind that extra info,
>>>>> >> but what makes
>>>>> >> some device unsafe to use isn't the age of the chips, but the age of
>>>>> >> the
>>>>> >> software)
>>>>> >>
>>>>> >> David Lang
>>>>> >>
>>>>> >> Bob
>>>>> >> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>>> >>
>>>>> >> There's also the concern about how do startups roll-out such a
>>>>> >> label for
>>>>> >> their tech in the early iteration phase? How do they afford to do
>>>>> >> the
>>>>> >> extra
>>>>> >> work for the label vs. a big company (does this become a regulatory
>>>>> >> moat?)
>>>>> >>
>>>>> >> And let's say we have these labels. Will only consumers with the
>>>>> >> money to
>>>>> >> purchase the more expensive equipment that has more privacy and
>>>>> >> security
>>>>> >> features buy that one - leaving those who cannot afford privacy and
>>>>> >> security bad alternatives?
>>>>> >>
>>>>> >> As far as security goes, I would argue that the easy answer is to
>>>>> >> ship
>>>>> >> a current version of openwrt instead of a forked, ancient version,
>>>>> >> and
>>>>> >> get their changes submitted upstream (or at least maintained against
>>>>> >> upstream). It's a different paradigm than they are used to, and
>>>>> >> right
>>>>> >> now the suppliers tend to also work with ancient versions of
>>>>> >> openwrt,
>>>>> >> but in all the companies that I have worked at, it's proven to be
>>>>> >> less
>>>>> >> ongoing work (and far less risk) to keep up with current versions
>>>>> >> than
>>>>> >> it is to stick with old versions and then do periodic 'big jump'
>>>>> >> upgrades.
>>>>> >>
>>>>> >> it's like car maintinance, it seems easier to ignore your tires,
>>>>> >> brakes, and oil changes, but the minimal cost of maintaining those
>>>>> >> systems pays off in a big way over time
>>>>> >>
>>>>> >> David Lang
>>>>> >>
>>>>> >> -------------------------
>>>>> >>
>>>>> >> Nnagain mailing list
>>>>> >> Nnagain@lists.bufferbloat.net
>>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>>> >>
>>>>> >> -------------------------
>>>>> >>
>>>>> >> Nnagain mailing list
>>>>> >> Nnagain@lists.bufferbloat.net
>>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>>> > _______________________________________________
>>>>> > Nnagain mailing list
>>>>> > Nnagain@lists.bufferbloat.net
>>>>> > https://lists.bufferbloat.net/listinfo/nnagain
>>>>> _______________________________________________
>>>>> Nnagain mailing list
>>>>> Nnagain@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>>> 
>

Re: [NNagain] Internet Education for Non-technorati?

[Robert McMahon]

[-- Attachment #1: Type: text/plain, Size: 12526 bytes --]

That's interesting. It's basically saying the security risk is openwrt sw. The chips themselves aren't, and signal processing is not either.

I'll add that to FiWi's remote radio head argument, i.e. it's inherently more secure. Security is a huge problem for everyone.

⁣Bob

On Oct 13, 2023, 1:34 AM, at 1:34 AM, David Lang <david@lang.hm> wrote:
>On Thu, 12 Oct 2023, rjmcmahon wrote:
>
>> I think we're looking at different parts of the elephant. I perceive
>huge
>> advances in WiFi (phy, dsp, radios, fems, etc.) and residential
>gateway chips
>> of late.
>
>My point is that the chips behavior doesn't change when you switch to a
>newer
>release of openwrt on the same chipset. When you do  a new hardware
>version, you
>need to do all the testing that was mentioned (and more) but if you are
>looking
>at updating the opewrt image, you have far less that you need to check.
>
>David Lang
>
>> Not sure the state of chips used by the openwrt folks here, though
>> they may be lagging a bit - not sure.
>>
>>
>https://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
>>
>> Broadcom’s Wi-Fi 7 ecosystem product portfolio includes the BCM6765,
>> BCM47722, and BCM4390.
>>
>> The BCM6765 is optimized for the residential Wi-Fi access point
>market. Key
>> features include:
>> ...
>> The BCM47722 is an enterprise access point platform SoC supporting
>Wi-Fi 7,
>> Bluetooth Low Energy, and 802.15.4 protocols. Key features include:
>> ...
>> The BCM4390 is a highly-integrated Wi-Fi 7 and Bluetooth 5 combo chip
>
>> optimized for mobile handset applications. Key features include:
>> ...
>>
>> Bob
>>> On Thu, 12 Oct 2023, rjmcmahon via Nnagain wrote:
>>>
>>>> I looked at openwrt packages and iperf 2 is  at version 2.1.3 which
>is a
>>>> few years old.
>>>>
>>>> The number of CPE/AP systems to test against is quite large. Then
>throwing
>>>> in versions for backwards compatibility testing adds yet another
>vector.
>>>
>>> for the market as a whole, yes, it's a hard problem. But for an
>>> individual manfacturer, they only have to work with their equipment,
>>> not all the others. The RF side isn't changing from release to
>release
>>> (and usually the firmware for the Wifi isn't changing), so that
>>> eliminates a lot of the work. They need to do more smoke testing of
>>> new releases than a full regression/performance test. Some
>>> incompatibility creeping in is the most likely problem, not a subtle
>>> performance issue.
>>>
>>> For the Scale conference, we have a Pi tied to a couple relays
>hooked
>>> to the motherboard of the router we use and it's tied in to our
>github
>>> repo, so every PR gets auto-flashed to the router and simple checks
>>> done. Things like this should be easy to setup and will catch most
>>> issues.
>>>
>>> David Lang
>>>
>>>> Since it's performance related, statistical techniques are required
>
>>>> against multiple metrics to measure statistically the same or not.
>Finally
>>>> with WiFi, one needs to throw in some controlled, repeatable RF
>>>> variability around the d-matrices (range) & h-matrices (frequency
>>>> responses in both phase and amplitudes per the MIMO spatial
>streams.)
>>>>
>>>> I can see why vendors (& system integrators) might be slow to adopt
>the
>>>> latest if there is not some sort of extensive qualification ahead
>of that
>>>> adoption.
>>>>
>>>> Bob
>>>>
>>>> PS. Iperf 2 now has 2.5+ million downloads (if sourceforge is to be
>
>>>> believed.) My wife suggested I write a book titled, "How to create
>>>> software with 2.5M downloads, a zero marginal cost to produce, and
>get
>>>> paid zero dollars!!" I suspect many openwrt & other programmers
>could add
>>>> multiple chapters to such a book.
>>>>
>>>>> On Thu, Oct 12, 2023 at 9:04 AM rjmcmahon via Nnagain
>>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>>>
>>>>>> Sorry, my openwrt information seems to be incorrect and more
>vendors use
>>>>>> openwrt then I realized. So, I really don't know the numbers
>here.
>>>>>
>>>>> There are not a lot of choices in the market. On the high end,
>like
>>>>> eero, we are seeing Debian derived systems, also some chromeOS
>>>>> devices. Lower end there is "buildroot", and forked openwrts like
>>>>> Meraki.
>>>>>
>>>>> So the whole home router and cpe market has some, usually
>obsolete,
>>>>> hacked up, and unmaintained version of openwrt at its heart, on
>>>>> everything from SFPs to the routers and a lot of iOt, despite many
>>>>> advancements and security patches in the main build.
>>>>>
>>>>> It would be my earnest hope, with a clear upgrade path, downstream
>>>>> manufacturers would release within a few months of the main
>OpenWrt
>>>>> releases, or even at the same time, having worked with their
>customers
>>>>> through the 6 month release candidate cycle. Microsoft
>accomplishes
>>>>> this, at least.
>>>>>
>>>>>
>>>>
>https://www.reddit.com/r/openwrt/comments/175z8t9/imminent_release_of_openwrt_2305/
>>>>>
>>>>>> I do agree with the idea that fixes should be pushed to the
>mainline and
>>>>>> that incremental upgrades should be standard practice.
>>>>>
>>>>> +1000
>>>>>
>>>>>> Arista's SW VP gave a talk where he said that 80% of their
>customer
>>>>>> calls about bugs were already fixed but their customer wasn't
>following
>>>>>> an upgrade policy. This approach applies to most any sw based
>product.
>>>>>
>>>>> +100
>>>>>
>>>>>>
>>>>>> Bob
>>>>>> > Hi David,
>>>>>> >
>>>>>> > The vendors I know don't roll their own os code either. The
>make their
>>>>>> > own release still mostly based from Linux and they aren't tied
>to the
>>>>>> > openwrt release process.
>>>>>> >
>>>>>> > I think GUIs on CPEs are the wrong direction. Consumer network
>>>>>> > equipment does best when it's plug and play. Consumers don't
>have all
>>>>>> > the skills needed to manage an in home packet network that
>includes
>>>>>> > wifi.
>>>>>> >
>>>>>> > I recently fixed a home network for my inlaws. It's a combo of
>>>>>> > structured wire and WiFi APs. I purchased the latest equipment
>from
>>>>>> > Amazon vs use the ISP provided equipment. I can do this
>reasonably
>>>>>> > well because I'm familiar with the chips inside.
>>>>>> >
>>>>>> > The online tech support started with trepidation as he was
>concerned
>>>>>> > that the home owner, i.e me, wasn't as skilled as the ISP
>technicians.
>>>>>> > He suggested we schedule that but I said we were good to go w/o
>one.
>>>>>> >
>>>>>> > He asked to speak to my father in law when we were all done. He
>told
>>>>>> > him, "You're lucky to have a son in law that know what he's
>doing. My
>>>>>> > techs aren't as good, and I really liked working with him too."
>>>>>> >
>>>>>> > I say this not to brag, as many on this list could do the
>equivalent,
>>>>>> > but to show that we really need to train lots of technicians on
>things
>>>>>> > like RF and structured wiring. Nobody should be "lucky" to get
>a
>>>>>> > quality in home network.  We're not lucky to have a flush
>toilet
>>>>>> > anymore. This stuff is too important to rely on luck.
>>>>>> >
>>>>>> > Bob
>>>>>> > On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>>>> >
>>>>>> >> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>>>> >>
>>>>>> >>> I don't know the numbers but a guess is that a majority of
>SoCs
>>>>>> >>> with WiFi
>>>>>> >>> radios aren't based on openwrt.
>>>>>> >>
>>>>>> >> From what I've seen, the majority of APs out there are based
>on
>>>>>> >> OpenWRT or one
>>>>>> >> of the competing open projects, very few roll their own OS
>from
>>>>>> >> scratch
>>>>>> >>
>>>>>> >>> I think many on this list use openwrt but
>>>>>> >>> that may not be representative of the actuals. Also, the
>trend is
>>>>>> >>> less sw in
>>>>>> >>> a CPU forwarding plane and more hw, one day, linux at the
>CPEs
>>>>>>
>mayhttps://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
>>>>>> >>> not be
>>>>>> >>> needed at all (if we get to remote radio heads - though this
>is
>>>>>> >>> highly
>>>>>> >>> speculative.)Peregrine - 112G PAM4
>>>>>> >>
>>>>>> >> that is countered by the trend to do more (fancier GUI, media
>>>>>> >> center, etc) The
>>>>>> >> vendors all want to differentiate themselves, that's hard to
>do if
>>>>>> >> it's baked
>>>>>> >> into the chips
>>>>>> >>
>>>>>> >>> From my experience, sw is defined by the number & frequency
>of
>>>>>> >>> commits, and
>>>>>> >>> of timeliness to issues more than a version number or compile
>>>>>> >>> date. So the
>>>>>> >>> size and quality of the software staff can be informative.
>>>>>> >>>
>>>>>> >>> I'm more interested in mfg node process then the mfg location
>&
>>>>>> >>> date as the
>>>>>> >>> node process gives an idea if the design is keeping up or
>not.
>>>>>> >>> Chips designed
>>>>>> >>> in 2012 are woefully behind and consume too much energy and
>>>>>> >>> generate too much
>>>>>> >>> heat. I think Intel provides this information on all its
>chips as
>>>>>> >>> an example.
>>>>>> >>
>>>>>> >> I'm far less concerned about the chips than the software.
>Security
>>>>>> >> holes are far
>>>>>> >> more likely in the software than the chips. The chips may
>limit the
>>>>>> >> max
>>>>>> >> performance of the devices, but the focus of this is on the
>>>>>> >> security, not the
>>>>>> >> throughput or the power efficiency (I don't mind that extra
>info,
>>>>>> >> but what makes
>>>>>> >> some device unsafe to use isn't the age of the chips, but the
>age of
>>>>>> >> the
>>>>>> >> software)
>>>>>> >>
>>>>>> >> David Lang
>>>>>> >>
>>>>>> >> Bob
>>>>>> >> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>>>> >>
>>>>>> >> There's also the concern about how do startups roll-out such a
>>>>>> >> label for
>>>>>> >> their tech in the early iteration phase? How do they afford to
>do
>>>>>> >> the
>>>>>> >> extra
>>>>>> >> work for the label vs. a big company (does this become a
>regulatory
>>>>>> >> moat?)
>>>>>> >>
>>>>>> >> And let's say we have these labels. Will only consumers with
>the
>>>>>> >> money to
>>>>>> >> purchase the more expensive equipment that has more privacy
>and
>>>>>> >> security
>>>>>> >> features buy that one - leaving those who cannot afford
>privacy and
>>>>>> >> security bad alternatives?
>>>>>> >>
>>>>>> >> As far as security goes, I would argue that the easy answer is
>to
>>>>>> >> ship
>>>>>> >> a current version of openwrt instead of a forked, ancient
>version,
>>>>>> >> and
>>>>>> >> get their changes submitted upstream (or at least maintained
>against
>>>>>> >> upstream). It's a different paradigm than they are used to,
>and
>>>>>> >> right
>>>>>> >> now the suppliers tend to also work with ancient versions of
>>>>>> >> openwrt,
>>>>>> >> but in all the companies that I have worked at, it's proven to
>be
>>>>>> >> less
>>>>>> >> ongoing work (and far less risk) to keep up with current
>versions
>>>>>> >> than
>>>>>> >> it is to stick with old versions and then do periodic 'big
>jump'
>>>>>> >> upgrades.
>>>>>> >>
>>>>>> >> it's like car maintinance, it seems easier to ignore your
>tires,
>>>>>> >> brakes, and oil changes, but the minimal cost of maintaining
>those
>>>>>> >> systems pays off in a big way over time
>>>>>> >>
>>>>>> >> David Lang
>>>>>> >>
>>>>>> >> -------------------------
>>>>>> >>
>>>>>> >> Nnagain mailing list
>>>>>> >> Nnagain@lists.bufferbloat.net
>>>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> >>
>>>>>> >> -------------------------
>>>>>> >>
>>>>>> >> Nnagain mailing list
>>>>>> >> Nnagain@lists.bufferbloat.net
>>>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> > _______________________________________________
>>>>>> > Nnagain mailing list
>>>>>> > Nnagain@lists.bufferbloat.net
>>>>>> > https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> _______________________________________________
>>>>>> Nnagain mailing list
>>>>>> Nnagain@lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>
>>

[-- Attachment #2: Type: text/html, Size: 17330 bytes --]

Re: [NNagain] Internet Education for Non-technorati?

[Sebastian Moeller]

Hi Bob,


> On Oct 13, 2023, at 06:31, rjmcmahon via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> 
> Hi David,
> 
> I think we're looking at different parts of the elephant. I perceive huge advances in WiFi (phy, dsp, radios, fems, etc.) and residential gateway chips of late. Not sure the state of chips used by the openwrt folks here,

	[SM] The core OpenWrt developers seem to be mostly software folks (that are occasionally hired-by/cooperating with hardware companies) so in a sense OpenWrt uses those "chips" that are available in (cheapish) WiFi APs/routers available on the market where the manufacturer is either opensource friendly (some NDAs seem to be acceptable at least to some of the developers) or where folks are eager enough to reverse engineer stuff. That leaves some large vendors pretty much out of the OpenWrt ecosystem... e.g. broadcom has a reputation as being opensource unfriendly and hence has a lot of SoC/chips that are not supported by the opensource OpenWrt mainline.... I guess there might be vendor-private SDKs for broadcom chips that are based on OpenWrt, but I am purely speculating... (I think there is mainline support for some/most? ethernet chips, and some mostly oder WiFi, but modern WiFi or stuff like DSL seems not supported).


> though they may be lagging a bit - not sure.
> 
> https://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
> 
> Broadcom’s Wi-Fi 7 ecosystem product portfolio includes the BCM6765, BCM47722, and BCM4390.
> 
> The BCM6765 is optimized for the residential Wi-Fi access point market. Key features include:
> ...
> The BCM47722 is an enterprise access point platform SoC supporting Wi-Fi 7, Bluetooth Low Energy, and 802.15.4 protocols. Key features include:
> ...
> The BCM4390 is a highly-integrated Wi-Fi 7 and Bluetooth 5 combo chip optimized for mobile handset applications. Key features include:
> ...

	[SM] Yeah, these are not supported by OpenWrt yet, and likely never will, unless Broadcom changes its stance towards coperation with opensource developers in that section of the market.

Regards
	Sebastian


> 
> Bob
>> On Thu, 12 Oct 2023, rjmcmahon via Nnagain wrote:
>>> I looked at openwrt packages and iperf 2 is  at version 2.1.3 which is a few years old.
>>> The number of CPE/AP systems to test against is quite large. Then throwing in versions for backwards compatibility testing adds yet another vector.
>> for the market as a whole, yes, it's a hard problem. But for an
>> individual manfacturer, they only have to work with their equipment,
>> not all the others. The RF side isn't changing from release to release
>> (and usually the firmware for the Wifi isn't changing), so that
>> eliminates a lot of the work. They need to do more smoke testing of
>> new releases than a full regression/performance test. Some
>> incompatibility creeping in is the most likely problem, not a subtle
>> performance issue.
>> For the Scale conference, we have a Pi tied to a couple relays hooked
>> to the motherboard of the router we use and it's tied in to our github
>> repo, so every PR gets auto-flashed to the router and simple checks
>> done. Things like this should be easy to setup and will catch most
>> issues.
>> David Lang
>>> Since it's performance related, statistical techniques are required against multiple metrics to measure statistically the same or not. Finally with WiFi, one needs to throw in some controlled, repeatable RF variability around the d-matrices (range) & h-matrices (frequency responses in both phase and amplitudes per the MIMO spatial streams.)
>>> I can see why vendors (& system integrators) might be slow to adopt the latest if there is not some sort of extensive qualification ahead of that adoption.
>>> Bob
>>> PS. Iperf 2 now has 2.5+ million downloads (if sourceforge is to be believed.) My wife suggested I write a book titled, "How to create software with 2.5M downloads, a zero marginal cost to produce, and get paid zero dollars!!" I suspect many openwrt & other programmers could add multiple chapters to such a book.
>>>> On Thu, Oct 12, 2023 at 9:04 AM rjmcmahon via Nnagain
>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>> Sorry, my openwrt information seems to be incorrect and more vendors use
>>>>> openwrt then I realized. So, I really don't know the numbers here.
>>>> There are not a lot of choices in the market. On the high end, like
>>>> eero, we are seeing Debian derived systems, also some chromeOS
>>>> devices. Lower end there is "buildroot", and forked openwrts like
>>>> Meraki.
>>>> So the whole home router and cpe market has some, usually obsolete,
>>>> hacked up, and unmaintained version of openwrt at its heart, on
>>>> everything from SFPs to the routers and a lot of iOt, despite many
>>>> advancements and security patches in the main build.
>>>> It would be my earnest hope, with a clear upgrade path, downstream
>>>> manufacturers would release within a few months of the main OpenWrt
>>>> releases, or even at the same time, having worked with their customers
>>>> through the 6 month release candidate cycle. Microsoft accomplishes
>>>> this, at least.
>>> https://www.reddit.com/r/openwrt/comments/175z8t9/imminent_release_of_openwrt_2305/
>>>>> I do agree with the idea that fixes should be pushed to the mainline and
>>>>> that incremental upgrades should be standard practice.
>>>> +1000
>>>>> Arista's SW VP gave a talk where he said that 80% of their customer
>>>>> calls about bugs were already fixed but their customer wasn't following
>>>>> an upgrade policy. This approach applies to most any sw based product.
>>>> +100
>>>>> Bob
>>>>> > Hi David,
>>>>> >
>>>>> > The vendors I know don't roll their own os code either. The make their
>>>>> > own release still mostly based from Linux and they aren't tied to the
>>>>> > openwrt release process.
>>>>> >
>>>>> > I think GUIs on CPEs are the wrong direction. Consumer network
>>>>> > equipment does best when it's plug and play. Consumers don't have all
>>>>> > the skills needed to manage an in home packet network that includes
>>>>> > wifi.
>>>>> >
>>>>> > I recently fixed a home network for my inlaws. It's a combo of
>>>>> > structured wire and WiFi APs. I purchased the latest equipment from
>>>>> > Amazon vs use the ISP provided equipment. I can do this reasonably
>>>>> > well because I'm familiar with the chips inside.
>>>>> >
>>>>> > The online tech support started with trepidation as he was concerned
>>>>> > that the home owner, i.e me, wasn't as skilled as the ISP technicians.
>>>>> > He suggested we schedule that but I said we were good to go w/o one.
>>>>> >
>>>>> > He asked to speak to my father in law when we were all done. He told
>>>>> > him, "You're lucky to have a son in law that know what he's doing. My
>>>>> > techs aren't as good, and I really liked working with him too."
>>>>> >
>>>>> > I say this not to brag, as many on this list could do the equivalent,
>>>>> > but to show that we really need to train lots of technicians on things
>>>>> > like RF and structured wiring. Nobody should be "lucky" to get a
>>>>> > quality in home network.  We're not lucky to have a flush toilet
>>>>> > anymore. This stuff is too important to rely on luck.
>>>>> >
>>>>> > Bob
>>>>> > On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>>> >
>>>>> >> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>>> >>
>>>>> >>> I don't know the numbers but a guess is that a majority of SoCs
>>>>> >>> with WiFi
>>>>> >>> radios aren't based on openwrt.
>>>>> >>
>>>>> >> From what I've seen, the majority of APs out there are based on
>>>>> >> OpenWRT or one
>>>>> >> of the competing open projects, very few roll their own OS from
>>>>> >> scratch
>>>>> >>
>>>>> >>> I think many on this list use openwrt but
>>>>> >>> that may not be representative of the actuals. Also, the trend is
>>>>> >>> less sw in
>>>>> >>> a CPU forwarding plane and more hw, one day, linux at the CPEs mayhttps://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
>>>>> >>> not be
>>>>> >>> needed at all (if we get to remote radio heads - though this is
>>>>> >>> highly
>>>>> >>> speculative.)Peregrine - 112G PAM4
>>>>> >>
>>>>> >> that is countered by the trend to do more (fancier GUI, media
>>>>> >> center, etc) The
>>>>> >> vendors all want to differentiate themselves, that's hard to do if
>>>>> >> it's baked
>>>>> >> into the chips
>>>>> >>
>>>>> >>> From my experience, sw is defined by the number & frequency of
>>>>> >>> commits, and
>>>>> >>> of timeliness to issues more than a version number or compile
>>>>> >>> date. So the
>>>>> >>> size and quality of the software staff can be informative.
>>>>> >>>
>>>>> >>> I'm more interested in mfg node process then the mfg location &
>>>>> >>> date as the
>>>>> >>> node process gives an idea if the design is keeping up or not.
>>>>> >>> Chips designed
>>>>> >>> in 2012 are woefully behind and consume too much energy and
>>>>> >>> generate too much
>>>>> >>> heat. I think Intel provides this information on all its chips as
>>>>> >>> an example.
>>>>> >>
>>>>> >> I'm far less concerned about the chips than the software. Security
>>>>> >> holes are far
>>>>> >> more likely in the software than the chips. The chips may limit the
>>>>> >> max
>>>>> >> performance of the devices, but the focus of this is on the
>>>>> >> security, not the
>>>>> >> throughput or the power efficiency (I don't mind that extra info,
>>>>> >> but what makes
>>>>> >> some device unsafe to use isn't the age of the chips, but the age of
>>>>> >> the
>>>>> >> software)
>>>>> >>
>>>>> >> David Lang
>>>>> >>
>>>>> >> Bob
>>>>> >> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>>> >>
>>>>> >> There's also the concern about how do startups roll-out such a
>>>>> >> label for
>>>>> >> their tech in the early iteration phase? How do they afford to do
>>>>> >> the
>>>>> >> extra
>>>>> >> work for the label vs. a big company (does this become a regulatory
>>>>> >> moat?)
>>>>> >>
>>>>> >> And let's say we have these labels. Will only consumers with the
>>>>> >> money to
>>>>> >> purchase the more expensive equipment that has more privacy and
>>>>> >> security
>>>>> >> features buy that one - leaving those who cannot afford privacy and
>>>>> >> security bad alternatives?
>>>>> >>
>>>>> >> As far as security goes, I would argue that the easy answer is to
>>>>> >> ship
>>>>> >> a current version of openwrt instead of a forked, ancient version,
>>>>> >> and
>>>>> >> get their changes submitted upstream (or at least maintained against
>>>>> >> upstream). It's a different paradigm than they are used to, and
>>>>> >> right
>>>>> >> now the suppliers tend to also work with ancient versions of
>>>>> >> openwrt,
>>>>> >> but in all the companies that I have worked at, it's proven to be
>>>>> >> less
>>>>> >> ongoing work (and far less risk) to keep up with current versions
>>>>> >> than
>>>>> >> it is to stick with old versions and then do periodic 'big jump'
>>>>> >> upgrades.
>>>>> >>
>>>>> >> it's like car maintinance, it seems easier to ignore your tires,
>>>>> >> brakes, and oil changes, but the minimal cost of maintaining those
>>>>> >> systems pays off in a big way over time
>>>>> >>
>>>>> >> David Lang
>>>>> >>
>>>>> >> -------------------------
>>>>> >>
>>>>> >> Nnagain mailing list
>>>>> >> Nnagain@lists.bufferbloat.net
>>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>>> >>
>>>>> >> -------------------------
>>>>> >>
>>>>> >> Nnagain mailing list
>>>>> >> Nnagain@lists.bufferbloat.net
>>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>>> > _______________________________________________
>>>>> > Nnagain mailing list
>>>>> > Nnagain@lists.bufferbloat.net
>>>>> > https://lists.bufferbloat.net/listinfo/nnagain
>>>>> _______________________________________________
>>>>> Nnagain mailing list
>>>>> Nnagain@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[rjmcmahon]

Hi Sebastian,

Sun workstations targeted engineers, many were sw engineers, who used 
the hardware to write sw for their workstations which was critical to 
success of the hardware & company. Sun was likely the very first open 
source company. Then hardware became more of a commodity where free sw 
couldn't pick up the slack. We all know what happened to Sun.

I think what we may be seeing is that the free software approach only 
works when engineers are the target market and buy enough hardware to 
sustain the business. The closest analogy of that today seems to be a 
raspberry pi.

I wonder if open source engineers could increase their innovation factor 
so hardware companies selling in units of millions per day, mostly 
through system integrators, would take notice? For example, there is 
nothing stopping a FiWi model today using rapsberry pis. Coupling 
management to something like VMWARE NSX might drive the opex down too.

A focus on open source sw innovation more tightly coupled to the massive 
NRE spends of semiconductors could be a game changer - not sure.

Bob

> Hi Bob,
> 
> 
>> On Oct 13, 2023, at 06:31, rjmcmahon via Nnagain 
>> <nnagain@lists.bufferbloat.net> wrote:
>> 
>> Hi David,
>> 
>> I think we're looking at different parts of the elephant. I perceive 
>> huge advances in WiFi (phy, dsp, radios, fems, etc.) and residential 
>> gateway chips of late. Not sure the state of chips used by the openwrt 
>> folks here,
> 
> 	[SM] The core OpenWrt developers seem to be mostly software folks
> (that are occasionally hired-by/cooperating with hardware companies)
> so in a sense OpenWrt uses those "chips" that are available in
> (cheapish) WiFi APs/routers available on the market where the
> manufacturer is either opensource friendly (some NDAs seem to be
> acceptable at least to some of the developers) or where folks are
> eager enough to reverse engineer stuff. That leaves some large vendors
> pretty much out of the OpenWrt ecosystem... e.g. broadcom has a
> reputation as being opensource unfriendly and hence has a lot of
> SoC/chips that are not supported by the opensource OpenWrt
> mainline.... I guess there might be vendor-private SDKs for broadcom
> chips that are based on OpenWrt, but I am purely speculating... (I
> think there is mainline support for some/most? ethernet chips, and
> some mostly oder WiFi, but modern WiFi or stuff like DSL seems not
> supported).
> 
> 
>> though they may be lagging a bit - not sure.
>> 
>> https://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
>> 
>> Broadcom’s Wi-Fi 7 ecosystem product portfolio includes the BCM6765, 
>> BCM47722, and BCM4390.
>> 
>> The BCM6765 is optimized for the residential Wi-Fi access point 
>> market. Key features include:
>> ...
>> The BCM47722 is an enterprise access point platform SoC supporting 
>> Wi-Fi 7, Bluetooth Low Energy, and 802.15.4 protocols. Key features 
>> include:
>> ...
>> The BCM4390 is a highly-integrated Wi-Fi 7 and Bluetooth 5 combo chip 
>> optimized for mobile handset applications. Key features include:
>> ...
> 
> 	[SM] Yeah, these are not supported by OpenWrt yet, and likely never
> will, unless Broadcom changes its stance towards coperation with
> opensource developers in that section of the market.
> 
> Regards
> 	Sebastian
> 
> 
>> 
>> Bob
>>> On Thu, 12 Oct 2023, rjmcmahon via Nnagain wrote:
>>>> I looked at openwrt packages and iperf 2 is  at version 2.1.3 which 
>>>> is a few years old.
>>>> The number of CPE/AP systems to test against is quite large. Then 
>>>> throwing in versions for backwards compatibility testing adds yet 
>>>> another vector.
>>> for the market as a whole, yes, it's a hard problem. But for an
>>> individual manfacturer, they only have to work with their equipment,
>>> not all the others. The RF side isn't changing from release to 
>>> release
>>> (and usually the firmware for the Wifi isn't changing), so that
>>> eliminates a lot of the work. They need to do more smoke testing of
>>> new releases than a full regression/performance test. Some
>>> incompatibility creeping in is the most likely problem, not a subtle
>>> performance issue.
>>> For the Scale conference, we have a Pi tied to a couple relays hooked
>>> to the motherboard of the router we use and it's tied in to our 
>>> github
>>> repo, so every PR gets auto-flashed to the router and simple checks
>>> done. Things like this should be easy to setup and will catch most
>>> issues.
>>> David Lang
>>>> Since it's performance related, statistical techniques are required 
>>>> against multiple metrics to measure statistically the same or not. 
>>>> Finally with WiFi, one needs to throw in some controlled, repeatable 
>>>> RF variability around the d-matrices (range) & h-matrices (frequency 
>>>> responses in both phase and amplitudes per the MIMO spatial 
>>>> streams.)
>>>> I can see why vendors (& system integrators) might be slow to adopt 
>>>> the latest if there is not some sort of extensive qualification 
>>>> ahead of that adoption.
>>>> Bob
>>>> PS. Iperf 2 now has 2.5+ million downloads (if sourceforge is to be 
>>>> believed.) My wife suggested I write a book titled, "How to create 
>>>> software with 2.5M downloads, a zero marginal cost to produce, and 
>>>> get paid zero dollars!!" I suspect many openwrt & other programmers 
>>>> could add multiple chapters to such a book.
>>>>> On Thu, Oct 12, 2023 at 9:04 AM rjmcmahon via Nnagain
>>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>>> Sorry, my openwrt information seems to be incorrect and more 
>>>>>> vendors use
>>>>>> openwrt then I realized. So, I really don't know the numbers here.
>>>>> There are not a lot of choices in the market. On the high end, like
>>>>> eero, we are seeing Debian derived systems, also some chromeOS
>>>>> devices. Lower end there is "buildroot", and forked openwrts like
>>>>> Meraki.
>>>>> So the whole home router and cpe market has some, usually obsolete,
>>>>> hacked up, and unmaintained version of openwrt at its heart, on
>>>>> everything from SFPs to the routers and a lot of iOt, despite many
>>>>> advancements and security patches in the main build.
>>>>> It would be my earnest hope, with a clear upgrade path, downstream
>>>>> manufacturers would release within a few months of the main OpenWrt
>>>>> releases, or even at the same time, having worked with their 
>>>>> customers
>>>>> through the 6 month release candidate cycle. Microsoft accomplishes
>>>>> this, at least.
>>>> https://www.reddit.com/r/openwrt/comments/175z8t9/imminent_release_of_openwrt_2305/
>>>>>> I do agree with the idea that fixes should be pushed to the 
>>>>>> mainline and
>>>>>> that incremental upgrades should be standard practice.
>>>>> +1000
>>>>>> Arista's SW VP gave a talk where he said that 80% of their 
>>>>>> customer
>>>>>> calls about bugs were already fixed but their customer wasn't 
>>>>>> following
>>>>>> an upgrade policy. This approach applies to most any sw based 
>>>>>> product.
>>>>> +100
>>>>>> Bob
>>>>>> > Hi David,
>>>>>> >
>>>>>> > The vendors I know don't roll their own os code either. The make their
>>>>>> > own release still mostly based from Linux and they aren't tied to the
>>>>>> > openwrt release process.
>>>>>> >
>>>>>> > I think GUIs on CPEs are the wrong direction. Consumer network
>>>>>> > equipment does best when it's plug and play. Consumers don't have all
>>>>>> > the skills needed to manage an in home packet network that includes
>>>>>> > wifi.
>>>>>> >
>>>>>> > I recently fixed a home network for my inlaws. It's a combo of
>>>>>> > structured wire and WiFi APs. I purchased the latest equipment from
>>>>>> > Amazon vs use the ISP provided equipment. I can do this reasonably
>>>>>> > well because I'm familiar with the chips inside.
>>>>>> >
>>>>>> > The online tech support started with trepidation as he was concerned
>>>>>> > that the home owner, i.e me, wasn't as skilled as the ISP technicians.
>>>>>> > He suggested we schedule that but I said we were good to go w/o one.
>>>>>> >
>>>>>> > He asked to speak to my father in law when we were all done. He told
>>>>>> > him, "You're lucky to have a son in law that know what he's doing. My
>>>>>> > techs aren't as good, and I really liked working with him too."
>>>>>> >
>>>>>> > I say this not to brag, as many on this list could do the equivalent,
>>>>>> > but to show that we really need to train lots of technicians on things
>>>>>> > like RF and structured wiring. Nobody should be "lucky" to get a
>>>>>> > quality in home network.  We're not lucky to have a flush toilet
>>>>>> > anymore. This stuff is too important to rely on luck.
>>>>>> >
>>>>>> > Bob
>>>>>> > On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>>>> >
>>>>>> >> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>>>> >>
>>>>>> >>> I don't know the numbers but a guess is that a majority of SoCs
>>>>>> >>> with WiFi
>>>>>> >>> radios aren't based on openwrt.
>>>>>> >>
>>>>>> >> From what I've seen, the majority of APs out there are based on
>>>>>> >> OpenWRT or one
>>>>>> >> of the competing open projects, very few roll their own OS from
>>>>>> >> scratch
>>>>>> >>
>>>>>> >>> I think many on this list use openwrt but
>>>>>> >>> that may not be representative of the actuals. Also, the trend is
>>>>>> >>> less sw in
>>>>>> >>> a CPU forwarding plane and more hw, one day, linux at the CPEs mayhttps://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
>>>>>> >>> not be
>>>>>> >>> needed at all (if we get to remote radio heads - though this is
>>>>>> >>> highly
>>>>>> >>> speculative.)Peregrine - 112G PAM4
>>>>>> >>
>>>>>> >> that is countered by the trend to do more (fancier GUI, media
>>>>>> >> center, etc) The
>>>>>> >> vendors all want to differentiate themselves, that's hard to do if
>>>>>> >> it's baked
>>>>>> >> into the chips
>>>>>> >>
>>>>>> >>> From my experience, sw is defined by the number & frequency of
>>>>>> >>> commits, and
>>>>>> >>> of timeliness to issues more than a version number or compile
>>>>>> >>> date. So the
>>>>>> >>> size and quality of the software staff can be informative.
>>>>>> >>>
>>>>>> >>> I'm more interested in mfg node process then the mfg location &
>>>>>> >>> date as the
>>>>>> >>> node process gives an idea if the design is keeping up or not.
>>>>>> >>> Chips designed
>>>>>> >>> in 2012 are woefully behind and consume too much energy and
>>>>>> >>> generate too much
>>>>>> >>> heat. I think Intel provides this information on all its chips as
>>>>>> >>> an example.
>>>>>> >>
>>>>>> >> I'm far less concerned about the chips than the software. Security
>>>>>> >> holes are far
>>>>>> >> more likely in the software than the chips. The chips may limit the
>>>>>> >> max
>>>>>> >> performance of the devices, but the focus of this is on the
>>>>>> >> security, not the
>>>>>> >> throughput or the power efficiency (I don't mind that extra info,
>>>>>> >> but what makes
>>>>>> >> some device unsafe to use isn't the age of the chips, but the age of
>>>>>> >> the
>>>>>> >> software)
>>>>>> >>
>>>>>> >> David Lang
>>>>>> >>
>>>>>> >> Bob
>>>>>> >> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>>>> >>
>>>>>> >> There's also the concern about how do startups roll-out such a
>>>>>> >> label for
>>>>>> >> their tech in the early iteration phase? How do they afford to do
>>>>>> >> the
>>>>>> >> extra
>>>>>> >> work for the label vs. a big company (does this become a regulatory
>>>>>> >> moat?)
>>>>>> >>
>>>>>> >> And let's say we have these labels. Will only consumers with the
>>>>>> >> money to
>>>>>> >> purchase the more expensive equipment that has more privacy and
>>>>>> >> security
>>>>>> >> features buy that one - leaving those who cannot afford privacy and
>>>>>> >> security bad alternatives?
>>>>>> >>
>>>>>> >> As far as security goes, I would argue that the easy answer is to
>>>>>> >> ship
>>>>>> >> a current version of openwrt instead of a forked, ancient version,
>>>>>> >> and
>>>>>> >> get their changes submitted upstream (or at least maintained against
>>>>>> >> upstream). It's a different paradigm than they are used to, and
>>>>>> >> right
>>>>>> >> now the suppliers tend to also work with ancient versions of
>>>>>> >> openwrt,
>>>>>> >> but in all the companies that I have worked at, it's proven to be
>>>>>> >> less
>>>>>> >> ongoing work (and far less risk) to keep up with current versions
>>>>>> >> than
>>>>>> >> it is to stick with old versions and then do periodic 'big jump'
>>>>>> >> upgrades.
>>>>>> >>
>>>>>> >> it's like car maintinance, it seems easier to ignore your tires,
>>>>>> >> brakes, and oil changes, but the minimal cost of maintaining those
>>>>>> >> systems pays off in a big way over time
>>>>>> >>
>>>>>> >> David Lang
>>>>>> >>
>>>>>> >> -------------------------
>>>>>> >>
>>>>>> >> Nnagain mailing list
>>>>>> >> Nnagain@lists.bufferbloat.net
>>>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> >>
>>>>>> >> -------------------------
>>>>>> >>
>>>>>> >> Nnagain mailing list
>>>>>> >> Nnagain@lists.bufferbloat.net
>>>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> > _______________________________________________
>>>>>> > Nnagain mailing list
>>>>>> > Nnagain@lists.bufferbloat.net
>>>>>> > https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> _______________________________________________
>>>>>> Nnagain mailing list
>>>>>> Nnagain@lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[Sebastian Moeller]

Hi Bob,


> On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> 
> Hi David, 
> 
> The vendors I know don't roll their own os code either. The make their own release still mostly based from Linux and they aren't tied to the openwrt release process. 
> 
> I think GUIs on CPEs are the wrong direction. Consumer network equipment does best when it's plug and play. Consumers don't have all the skills needed to manage an in home packet network that includes wifi.

	[SM] That is both true, and (currently?) unachievable. To run a network connected to the internet securely requires to make a number of policy decisions trading-off the required/desired connectivity versus the cost in security (either cost as effort of maintaining security or cost in an increase in attack surface).
	The in-side the home situation, has IMHO drastically improved with the availability of off-the-shelf mesh network gear from commercial vendors, with easy to follow instructions and/or apps to find decent AP placement.
	For structured wiring, I would agree that requires both an unusual skill set (even though doing structured wiring itself is not hard, just doing it in a way that blends into an apartment without signaling DIY-ness is more involved).


> I recently fixed a home network for my inlaws. It's a combo of structured wire and WiFi APs. I purchased the latest equipment from Amazon vs use the ISP provided equipment. I can do this reasonably well because I'm familiar with the chips inside.
> 
> The online tech support started with trepidation as he was concerned that the home owner, i.e me, wasn't as skilled as the ISP technicians. He suggested we schedule that but I said we were good to go w/o one. 

	[SM] What "online tech support"? From the AP vendor or from the ISP? The latter might have a script recommending ISP technicians more for commercial considerations than technical ones...


> He asked to speak to my father in law when we were all done. He told him, "You're lucky to have a son in law that know what he's doing. My techs aren't as good, and I really liked working with him too."
> 
> I say this not to brag, as many on this list could do the equivalent, but to show that we really need to train lots of technicians on things like RF and structured wiring. Nobody should be "lucky" to get a quality in home network.  We're not lucky to have a flush toilet anymore. This stuff is too important to rely on luck.

	[SM] Mmmh, that got me thinking, maybe we should think about always running network wiring parallel to electric cables so each power socket could easily house an ethernet plug as well... (or one per room to keep the cost lower and avoid overly much "dark" copper)? Sort of put this into the building codes/best current practice documents... (I understand starting now, will still only solve the issue over many decades, but at least we would be making some inroads; and speaking of decades, maybe putting fiber there instead of copper might be a more future-oriented approach)?


> 
> Bob
> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
> On Wed, 11 Oct 2023, rjmcmahon wrote:
> 
>  I don't know the numbers but a guess is that a majority of SoCs with WiFi 
>  radios aren't based on openwrt.
> 
> From what I've seen, the majority of APs out there are based on OpenWRT or one 
> of the competing open projects, very few roll their own OS from scratch
> 
>  I think many on this list use openwrt but 
>  that may not be representative of the actuals. Also, the trend is less sw in 
>  a CPU forwarding plane and more hw, one day, linux at the CPEs may not be 
>  needed at all (if we get to remote radio heads - though this is highly 
>  speculative.)
> 
> that is countered by the trend to do more (fancier GUI, media center, etc) The 
> vendors all want to differentiate themselves, that's hard to do if it's baked 
> into the chips
> 
>  From my experience, sw is defined by the number & frequency of commits, and 
>  of timeliness to issues more than a version number or compile date. So the 
>  size and quality of the software staff can be informative.
> 
>  I'm more interested in mfg node process then the mfg location & date as the 
>  node process gives an idea if the design is keeping up or not. Chips designed 
>  in 2012 are woefully behind and consume too much energy and generate too much 
>  heat. I think Intel provides this information on all its chips as an example.
> 
> I'm far less concerned about the chips than the software. Security holes are far 
> more likely in the software than the chips. The chips may limit the max 
> performance of the devices, but the focus of this is on the security, not the 
> throughput or the power efficiency (I don't mind that extra info, but what makes 
> some device unsafe to use isn't the age of the chips, but the age of the 
> software)
> 
> David Lang
> 
>  Bob
>  On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>  
>  There's also the concern about how do startups roll-out such a label for
>  their tech in the early iteration phase? How do they afford to do the 
>  extra
>  work for the label vs. a big company (does this become a regulatory moat?)
>  
>  And let's say we have these labels. Will only consumers with the money to
>  purchase the more expensive equipment that has more privacy and security
>  features buy that one - leaving those who cannot afford privacy and
>  security bad alternatives?
>  
>  As far as security goes, I would argue that the easy answer is to ship
>  a current version of openwrt instead of a forked, ancient version, and
>  get their changes submitted upstream (or at least maintained against
>  upstream). It's a different paradigm than they are used to, and right
>  now the suppliers tend to also work with ancient versions of openwrt,
>  but in all the companies that I have worked at, it's proven to be less
>  ongoing work (and far less risk) to keep up with current versions than
>  it is to stick with old versions and then do periodic 'big jump'
>  upgrades.
>  
>  it's like car maintinance, it seems easier to ignore your tires,
>  brakes, and oil changes, but the minimal cost of maintaining those
>  systems pays off in a big way over time
>  
>  David Lang
> 
>  Nnagain mailing list
>  Nnagain@lists.bufferbloat.net
>  https://lists.bufferbloat.net/listinfo/nnagain
>  
> 
>  Nnagain mailing list
>  Nnagain@lists.bufferbloat.net
>  https://lists.bufferbloat.net/listinfo/nnagain
> 
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[rjmcmahon]

Hi Sebastian,

It was the ISP tech support over the phone. Trying to help install a 
home network over the phone w/o a technician isn't easy.

In many U.S. states, smoke detectors are required to be no more that 30' 
apart, must be AC powered, battery backed up and must communicate with 
one another. The smoke sensor needs to be replaced every ten years max.

It's a good place to install remote radio heads, or even full blown APs, 
for both internet access points and for life support sensors.

10G NRE spends stopped over a decade ago. Early adopters aren't likely 
going to wire 10G over copper in their homes. 100G only goes 4 meters so 
copper really isn't an option for future proof comm cable throughout 
buildings. Fiber to WiFi seems straight forward to me.

People don't want to be leashed to plugs so the last meters have to be 
wireless. We need to standardized to the extent that we can on one 
wireless tech (similar to Ethernet for wired) and a proposal is to use 
802.11 since that's selling in volume, driven by mobile hand sets.

Bob
> Hi Bob,
> 
> 
>> On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain 
>> <nnagain@lists.bufferbloat.net> wrote:
>> 
>> Hi David,
>> 
>> The vendors I know don't roll their own os code either. The make their 
>> own release still mostly based from Linux and they aren't tied to the 
>> openwrt release process.
>> 
>> I think GUIs on CPEs are the wrong direction. Consumer network 
>> equipment does best when it's plug and play. Consumers don't have all 
>> the skills needed to manage an in home packet network that includes 
>> wifi.
> 
> 	[SM] That is both true, and (currently?) unachievable. To run a
> network connected to the internet securely requires to make a number
> of policy decisions trading-off the required/desired connectivity
> versus the cost in security (either cost as effort of maintaining
> security or cost in an increase in attack surface).
> 	The in-side the home situation, has IMHO drastically improved with
> the availability of off-the-shelf mesh network gear from commercial
> vendors, with easy to follow instructions and/or apps to find decent
> AP placement.
> 	For structured wiring, I would agree that requires both an unusual
> skill set (even though doing structured wiring itself is not hard,
> just doing it in a way that blends into an apartment without signaling
> DIY-ness is more involved).
> 
> 
>> I recently fixed a home network for my inlaws. It's a combo of 
>> structured wire and WiFi APs. I purchased the latest equipment from 
>> Amazon vs use the ISP provided equipment. I can do this reasonably 
>> well because I'm familiar with the chips inside.
>> 
>> The online tech support started with trepidation as he was concerned 
>> that the home owner, i.e me, wasn't as skilled as the ISP technicians. 
>> He suggested we schedule that but I said we were good to go w/o one.
> 
> 	[SM] What "online tech support"? From the AP vendor or from the ISP?
> The latter might have a script recommending ISP technicians more for
> commercial considerations than technical ones...
> 
> 
>> He asked to speak to my father in law when we were all done. He told 
>> him, "You're lucky to have a son in law that know what he's doing. My 
>> techs aren't as good, and I really liked working with him too."
>> 
>> I say this not to brag, as many on this list could do the equivalent, 
>> but to show that we really need to train lots of technicians on things 
>> like RF and structured wiring. Nobody should be "lucky" to get a 
>> quality in home network.  We're not lucky to have a flush toilet 
>> anymore. This stuff is too important to rely on luck.
> 
> 	[SM] Mmmh, that got me thinking, maybe we should think about always
> running network wiring parallel to electric cables so each power
> socket could easily house an ethernet plug as well... (or one per room
> to keep the cost lower and avoid overly much "dark" copper)? Sort of
> put this into the building codes/best current practice documents... (I
> understand starting now, will still only solve the issue over many
> decades, but at least we would be making some inroads; and speaking of
> decades, maybe putting fiber there instead of copper might be a more
> future-oriented approach)?
> 
> 
>> 
>> Bob
>> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>> On Wed, 11 Oct 2023, rjmcmahon wrote:
>> 
>>  I don't know the numbers but a guess is that a majority of SoCs with 
>> WiFi
>>  radios aren't based on openwrt.
>> 
>> From what I've seen, the majority of APs out there are based on 
>> OpenWRT or one
>> of the competing open projects, very few roll their own OS from 
>> scratch
>> 
>>  I think many on this list use openwrt but
>>  that may not be representative of the actuals. Also, the trend is 
>> less sw in
>>  a CPU forwarding plane and more hw, one day, linux at the CPEs may 
>> not be
>>  needed at all (if we get to remote radio heads - though this is 
>> highly
>>  speculative.)
>> 
>> that is countered by the trend to do more (fancier GUI, media center, 
>> etc) The
>> vendors all want to differentiate themselves, that's hard to do if 
>> it's baked
>> into the chips
>> 
>>  From my experience, sw is defined by the number & frequency of 
>> commits, and
>>  of timeliness to issues more than a version number or compile date. 
>> So the
>>  size and quality of the software staff can be informative.
>> 
>>  I'm more interested in mfg node process then the mfg location & date 
>> as the
>>  node process gives an idea if the design is keeping up or not. Chips 
>> designed
>>  in 2012 are woefully behind and consume too much energy and generate 
>> too much
>>  heat. I think Intel provides this information on all its chips as an 
>> example.
>> 
>> I'm far less concerned about the chips than the software. Security 
>> holes are far
>> more likely in the software than the chips. The chips may limit the 
>> max
>> performance of the devices, but the focus of this is on the security, 
>> not the
>> throughput or the power efficiency (I don't mind that extra info, but 
>> what makes
>> some device unsafe to use isn't the age of the chips, but the age of 
>> the
>> software)
>> 
>> David Lang
>> 
>>  Bob
>>  On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>> 
>>  There's also the concern about how do startups roll-out such a label 
>> for
>>  their tech in the early iteration phase? How do they afford to do the
>>  extra
>>  work for the label vs. a big company (does this become a regulatory 
>> moat?)
>> 
>>  And let's say we have these labels. Will only consumers with the 
>> money to
>>  purchase the more expensive equipment that has more privacy and 
>> security
>>  features buy that one - leaving those who cannot afford privacy and
>>  security bad alternatives?
>> 
>>  As far as security goes, I would argue that the easy answer is to 
>> ship
>>  a current version of openwrt instead of a forked, ancient version, 
>> and
>>  get their changes submitted upstream (or at least maintained against
>>  upstream). It's a different paradigm than they are used to, and right
>>  now the suppliers tend to also work with ancient versions of openwrt,
>>  but in all the companies that I have worked at, it's proven to be 
>> less
>>  ongoing work (and far less risk) to keep up with current versions 
>> than
>>  it is to stick with old versions and then do periodic 'big jump'
>>  upgrades.
>> 
>>  it's like car maintinance, it seems easier to ignore your tires,
>>  brakes, and oil changes, but the minimal cost of maintaining those
>>  systems pays off in a big way over time
>> 
>>  David Lang
>> 
>>  Nnagain mailing list
>>  Nnagain@lists.bufferbloat.net
>>  https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> 
>>  Nnagain mailing list
>>  Nnagain@lists.bufferbloat.net
>>  https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[Sebastian Moeller]

Hi Bob,


> On Oct 13, 2023, at 19:20, rjmcmahon <rjmcmahon@rjmcmahon.com> wrote:
> 
> Hi Sebastian,
> 
> It was the ISP tech support over the phone. Trying to help install a home network over the phone w/o a technician isn't easy.

	[SM] Ah, okay. I would never even think about calling my ISP when considering changes to my home network (for one, I would rather McGywer this, and also my ISP does not really offer that as a servicedsdw), I guess different service offerings in different countries.


> In many U.S. states, smoke detectors are required to be no more that 30' apart, must be AC powered, battery backed up and must communicate with one another. The smoke sensor needs to be replaced every ten years max.

	[SM] Intersting! Over here detectors are also mandatory (but no distance or networking requirements, it is special rooms like bed rooms that need to have one). Also over here no AC requirement.


> It's a good place to install remote radio heads, or even full blown APs, for both internet access points and for life support sensors.

	[SM] I agree, and with an AC requirement powering such APs/radio heads is not rocket science either, heck in a first iteration one might even use PLC to bring data to the APs...


> 10G NRE spends stopped over a decade ago. Early adopters aren't likely going to wire 10G over copper in their homes.

	[SM] Over here active 2.5 Gbps ethernet are just becoming cheap enough for enthusiasts to switch over to, and 2.5 has the advantage of operating well even over most cat5 wiring (few homes I know will push anywhere close to the typical 100m copper ethernet limit, most will be fine with < 30m).


> 100G only goes 4 meters so copper really isn't an option for future proof comm cable throughout buildings.

	[SM] Indeed, but I am not 100% sure what use-case would justify going 100Gbps in a typical home? Sure if one switches to fiber wiring and 100Gbps is only marginally more expensive than 1 or 10 Gbps why not? 

> Fiber to WiFi seems straight forward to me.

	[SM] This might be related to your professional background though? ;) Just kidding, I think you are simply a few years ahead of the rest of us, as you know what is in the pipeline.


> People don't want to be leashed to plugs so the last meters have to be wireless.

	[SM] Yes and no. People did not bother about wiring office desks or even smart TVs, but smart phones and tablets are a different kettle of fish, as are laptops, that might be operated wired on the desk but wireless in the rest of the house. I also note that more and more laptops come without built in ethernet (personally I detest that, an rj45 jack is not that thick that a laptop body can not be planned around that, leaving some more room for e.g. NVMe sockets or simplify cooling a bit, ultra-thin is IMHO not really in the end-users' interest, but I digress).


> We need to standardized to the extent that we can on one wireless tech (similar to Ethernet for wired) and a proposal is to use 802.11 since that's selling in volume, driven by mobile hand sets.

	[SM] Sure 802.11 is likely to stay by virtue of being relatively ubiquitous and by being generally already good enough for many use cases (with road-maps for tackling more demanding use-cases, and I very much include your fiwi proposal here).



> 
> Bob
>> Hi Bob,
>>> On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain <nnagain@lists.bufferbloat.net> wrote:
>>> Hi David,
>>> The vendors I know don't roll their own os code either. The make their own release still mostly based from Linux and they aren't tied to the openwrt release process.
>>> I think GUIs on CPEs are the wrong direction. Consumer network equipment does best when it's plug and play. Consumers don't have all the skills needed to manage an in home packet network that includes wifi.
>> 	[SM] That is both true, and (currently?) unachievable. To run a
>> network connected to the internet securely requires to make a number
>> of policy decisions trading-off the required/desired connectivity
>> versus the cost in security (either cost as effort of maintaining
>> security or cost in an increase in attack surface).
>> 	The in-side the home situation, has IMHO drastically improved with
>> the availability of off-the-shelf mesh network gear from commercial
>> vendors, with easy to follow instructions and/or apps to find decent
>> AP placement.
>> 	For structured wiring, I would agree that requires both an unusual
>> skill set (even though doing structured wiring itself is not hard,
>> just doing it in a way that blends into an apartment without signaling
>> DIY-ness is more involved).
>>> I recently fixed a home network for my inlaws. It's a combo of structured wire and WiFi APs. I purchased the latest equipment from Amazon vs use the ISP provided equipment. I can do this reasonably well because I'm familiar with the chips inside.
>>> The online tech support started with trepidation as he was concerned that the home owner, i.e me, wasn't as skilled as the ISP technicians. He suggested we schedule that but I said we were good to go w/o one.
>> 	[SM] What "online tech support"? From the AP vendor or from the ISP?
>> The latter might have a script recommending ISP technicians more for
>> commercial considerations than technical ones...
>>> He asked to speak to my father in law when we were all done. He told him, "You're lucky to have a son in law that know what he's doing. My techs aren't as good, and I really liked working with him too."
>>> I say this not to brag, as many on this list could do the equivalent, but to show that we really need to train lots of technicians on things like RF and structured wiring. Nobody should be "lucky" to get a quality in home network.  We're not lucky to have a flush toilet anymore. This stuff is too important to rely on luck.
>> 	[SM] Mmmh, that got me thinking, maybe we should think about always
>> running network wiring parallel to electric cables so each power
>> socket could easily house an ethernet plug as well... (or one per room
>> to keep the cost lower and avoid overly much "dark" copper)? Sort of
>> put this into the building codes/best current practice documents... (I
>> understand starting now, will still only solve the issue over many
>> decades, but at least we would be making some inroads; and speaking of
>> decades, maybe putting fiber there instead of copper might be a more
>> future-oriented approach)?
>>> Bob
>>> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>> I don't know the numbers but a guess is that a majority of SoCs with WiFi
>>> radios aren't based on openwrt.
>>> From what I've seen, the majority of APs out there are based on OpenWRT or one
>>> of the competing open projects, very few roll their own OS from scratch
>>> I think many on this list use openwrt but
>>> that may not be representative of the actuals. Also, the trend is less sw in
>>> a CPU forwarding plane and more hw, one day, linux at the CPEs may not be
>>> needed at all (if we get to remote radio heads - though this is highly
>>> speculative.)
>>> that is countered by the trend to do more (fancier GUI, media center, etc) The
>>> vendors all want to differentiate themselves, that's hard to do if it's baked
>>> into the chips
>>> From my experience, sw is defined by the number & frequency of commits, and
>>> of timeliness to issues more than a version number or compile date. So the
>>> size and quality of the software staff can be informative.
>>> I'm more interested in mfg node process then the mfg location & date as the
>>> node process gives an idea if the design is keeping up or not. Chips designed
>>> in 2012 are woefully behind and consume too much energy and generate too much
>>> heat. I think Intel provides this information on all its chips as an example.
>>> I'm far less concerned about the chips than the software. Security holes are far
>>> more likely in the software than the chips. The chips may limit the max
>>> performance of the devices, but the focus of this is on the security, not the
>>> throughput or the power efficiency (I don't mind that extra info, but what makes
>>> some device unsafe to use isn't the age of the chips, but the age of the
>>> software)
>>> David Lang
>>> Bob
>>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>> There's also the concern about how do startups roll-out such a label for
>>> their tech in the early iteration phase? How do they afford to do the
>>> extra
>>> work for the label vs. a big company (does this become a regulatory moat?)
>>> And let's say we have these labels. Will only consumers with the money to
>>> purchase the more expensive equipment that has more privacy and security
>>> features buy that one - leaving those who cannot afford privacy and
>>> security bad alternatives?
>>> As far as security goes, I would argue that the easy answer is to ship
>>> a current version of openwrt instead of a forked, ancient version, and
>>> get their changes submitted upstream (or at least maintained against
>>> upstream). It's a different paradigm than they are used to, and right
>>> now the suppliers tend to also work with ancient versions of openwrt,
>>> but in all the companies that I have worked at, it's proven to be less
>>> ongoing work (and far less risk) to keep up with current versions than
>>> it is to stick with old versions and then do periodic 'big jump'
>>> upgrades.
>>> it's like car maintinance, it seems easier to ignore your tires,
>>> brakes, and oil changes, but the minimal cost of maintaining those
>>> systems pays off in a big way over time
>>> David Lang
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[rjmcmahon]

Hi Sebastian,

On being unleashed, I think this applies to consumer electronics too. 
Not sure why HDMI class cables will be needed. WiFi 7 is spec'd at 16 
MIMO radios at 45Gb/s per front end module. Add some hw 
compression/decompression, I think it can carry even HDMI Utlra High 
Speed or 8K. And the content will likely be coming from the cloud too, 
so the need for a short HDMI cable kinda goes away.

Maybe I'm unique of being tired of having rats' nests of cables to 
connect things. My thoughts are no more cables other than structured 
fiber and structured AC which both are long lived, multiple decades or 
more, and hence are a one and done type of spend.

I'm not a fan of PLC, mixing power and comm. I've installed AFCI circuit 
breakers for all my family, including the in laws. These can trigger 
easily when other signals are multiplexed.

There were so many things that went wrong in The Bronx where 11 people 
died including children. An AFCI breaker would likely have prevented 
that fire. Working auto door closers would have helped. Providing heat 
pumps would have helped too so kids didn't have to use electric 
resistive space heaters which are terrible by my judgment.

It's hard to believe that Notre Dame burned down too. We've got so 
improvement to do on life support systems.

https://en.wikipedia.org/wiki/2022_Bronx_apartment_fire

Bob
> Hi Bob,
> 
> 
>> On Oct 13, 2023, at 19:20, rjmcmahon <rjmcmahon@rjmcmahon.com> wrote:
>> 
>> Hi Sebastian,
>> 
>> It was the ISP tech support over the phone. Trying to help install a 
>> home network over the phone w/o a technician isn't easy.
> 
> 	[SM] Ah, okay. I would never even think about calling my ISP when
> considering changes to my home network (for one, I would rather
> McGywer this, and also my ISP does not really offer that as a
> servicedsdw), I guess different service offerings in different
> countries.
> 
> 
>> In many U.S. states, smoke detectors are required to be no more that 
>> 30' apart, must be AC powered, battery backed up and must communicate 
>> with one another. The smoke sensor needs to be replaced every ten 
>> years max.
> 
> 	[SM] Intersting! Over here detectors are also mandatory (but no
> distance or networking requirements, it is special rooms like bed
> rooms that need to have one). Also over here no AC requirement.
> 
> 
>> It's a good place to install remote radio heads, or even full blown 
>> APs, for both internet access points and for life support sensors.
> 
> 	[SM] I agree, and with an AC requirement powering such APs/radio
> heads is not rocket science either, heck in a first iteration one
> might even use PLC to bring data to the APs...
> 
> 
>> 10G NRE spends stopped over a decade ago. Early adopters aren't likely 
>> going to wire 10G over copper in their homes.
> 
> 	[SM] Over here active 2.5 Gbps ethernet are just becoming cheap
> enough for enthusiasts to switch over to, and 2.5 has the advantage of
> operating well even over most cat5 wiring (few homes I know will push
> anywhere close to the typical 100m copper ethernet limit, most will be
> fine with < 30m).
> 
> 
>> 100G only goes 4 meters so copper really isn't an option for future 
>> proof comm cable throughout buildings.
> 
> 	[SM] Indeed, but I am not 100% sure what use-case would justify going
> 100Gbps in a typical home? Sure if one switches to fiber wiring and
> 100Gbps is only marginally more expensive than 1 or 10 Gbps why not?
> 
>> Fiber to WiFi seems straight forward to me.
> 
> 	[SM] This might be related to your professional background though? ;)
> Just kidding, I think you are simply a few years ahead of the rest of
> us, as you know what is in the pipeline.
> 
> 
>> People don't want to be leashed to plugs so the last meters have to be 
>> wireless.
> 
> 	[SM] Yes and no. People did not bother about wiring office desks or
> even smart TVs, but smart phones and tablets are a different kettle of
> fish, as are laptops, that might be operated wired on the desk but
> wireless in the rest of the house. I also note that more and more
> laptops come without built in ethernet (personally I detest that, an
> rj45 jack is not that thick that a laptop body can not be planned
> around that, leaving some more room for e.g. NVMe sockets or simplify
> cooling a bit, ultra-thin is IMHO not really in the end-users'
> interest, but I digress).
> 
> 
>> We need to standardized to the extent that we can on one wireless tech 
>> (similar to Ethernet for wired) and a proposal is to use 802.11 since 
>> that's selling in volume, driven by mobile hand sets.
> 
> 	[SM] Sure 802.11 is likely to stay by virtue of being relatively
> ubiquitous and by being generally already good enough for many use
> cases (with road-maps for tackling more demanding use-cases, and I
> very much include your fiwi proposal here).
> 
> 
> 
>> 
>> Bob
>>> Hi Bob,
>>>> On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain 
>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>> Hi David,
>>>> The vendors I know don't roll their own os code either. The make 
>>>> their own release still mostly based from Linux and they aren't tied 
>>>> to the openwrt release process.
>>>> I think GUIs on CPEs are the wrong direction. Consumer network 
>>>> equipment does best when it's plug and play. Consumers don't have 
>>>> all the skills needed to manage an in home packet network that 
>>>> includes wifi.
>>> 	[SM] That is both true, and (currently?) unachievable. To run a
>>> network connected to the internet securely requires to make a number
>>> of policy decisions trading-off the required/desired connectivity
>>> versus the cost in security (either cost as effort of maintaining
>>> security or cost in an increase in attack surface).
>>> 	The in-side the home situation, has IMHO drastically improved with
>>> the availability of off-the-shelf mesh network gear from commercial
>>> vendors, with easy to follow instructions and/or apps to find decent
>>> AP placement.
>>> 	For structured wiring, I would agree that requires both an unusual
>>> skill set (even though doing structured wiring itself is not hard,
>>> just doing it in a way that blends into an apartment without 
>>> signaling
>>> DIY-ness is more involved).
>>>> I recently fixed a home network for my inlaws. It's a combo of 
>>>> structured wire and WiFi APs. I purchased the latest equipment from 
>>>> Amazon vs use the ISP provided equipment. I can do this reasonably 
>>>> well because I'm familiar with the chips inside.
>>>> The online tech support started with trepidation as he was concerned 
>>>> that the home owner, i.e me, wasn't as skilled as the ISP 
>>>> technicians. He suggested we schedule that but I said we were good 
>>>> to go w/o one.
>>> 	[SM] What "online tech support"? From the AP vendor or from the ISP?
>>> The latter might have a script recommending ISP technicians more for
>>> commercial considerations than technical ones...
>>>> He asked to speak to my father in law when we were all done. He told 
>>>> him, "You're lucky to have a son in law that know what he's doing. 
>>>> My techs aren't as good, and I really liked working with him too."
>>>> I say this not to brag, as many on this list could do the 
>>>> equivalent, but to show that we really need to train lots of 
>>>> technicians on things like RF and structured wiring. Nobody should 
>>>> be "lucky" to get a quality in home network.  We're not lucky to 
>>>> have a flush toilet anymore. This stuff is too important to rely on 
>>>> luck.
>>> 	[SM] Mmmh, that got me thinking, maybe we should think about always
>>> running network wiring parallel to electric cables so each power
>>> socket could easily house an ethernet plug as well... (or one per 
>>> room
>>> to keep the cost lower and avoid overly much "dark" copper)? Sort of
>>> put this into the building codes/best current practice documents... 
>>> (I
>>> understand starting now, will still only solve the issue over many
>>> decades, but at least we would be making some inroads; and speaking 
>>> of
>>> decades, maybe putting fiber there instead of copper might be a more
>>> future-oriented approach)?
>>>> Bob
>>>> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>> I don't know the numbers but a guess is that a majority of SoCs with 
>>>> WiFi
>>>> radios aren't based on openwrt.
>>>> From what I've seen, the majority of APs out there are based on 
>>>> OpenWRT or one
>>>> of the competing open projects, very few roll their own OS from 
>>>> scratch
>>>> I think many on this list use openwrt but
>>>> that may not be representative of the actuals. Also, the trend is 
>>>> less sw in
>>>> a CPU forwarding plane and more hw, one day, linux at the CPEs may 
>>>> not be
>>>> needed at all (if we get to remote radio heads - though this is 
>>>> highly
>>>> speculative.)
>>>> that is countered by the trend to do more (fancier GUI, media 
>>>> center, etc) The
>>>> vendors all want to differentiate themselves, that's hard to do if 
>>>> it's baked
>>>> into the chips
>>>> From my experience, sw is defined by the number & frequency of 
>>>> commits, and
>>>> of timeliness to issues more than a version number or compile date. 
>>>> So the
>>>> size and quality of the software staff can be informative.
>>>> I'm more interested in mfg node process then the mfg location & date 
>>>> as the
>>>> node process gives an idea if the design is keeping up or not. Chips 
>>>> designed
>>>> in 2012 are woefully behind and consume too much energy and generate 
>>>> too much
>>>> heat. I think Intel provides this information on all its chips as an 
>>>> example.
>>>> I'm far less concerned about the chips than the software. Security 
>>>> holes are far
>>>> more likely in the software than the chips. The chips may limit the 
>>>> max
>>>> performance of the devices, but the focus of this is on the 
>>>> security, not the
>>>> throughput or the power efficiency (I don't mind that extra info, 
>>>> but what makes
>>>> some device unsafe to use isn't the age of the chips, but the age of 
>>>> the
>>>> software)
>>>> David Lang
>>>> Bob
>>>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>> There's also the concern about how do startups roll-out such a label 
>>>> for
>>>> their tech in the early iteration phase? How do they afford to do 
>>>> the
>>>> extra
>>>> work for the label vs. a big company (does this become a regulatory 
>>>> moat?)
>>>> And let's say we have these labels. Will only consumers with the 
>>>> money to
>>>> purchase the more expensive equipment that has more privacy and 
>>>> security
>>>> features buy that one - leaving those who cannot afford privacy and
>>>> security bad alternatives?
>>>> As far as security goes, I would argue that the easy answer is to 
>>>> ship
>>>> a current version of openwrt instead of a forked, ancient version, 
>>>> and
>>>> get their changes submitted upstream (or at least maintained against
>>>> upstream). It's a different paradigm than they are used to, and 
>>>> right
>>>> now the suppliers tend to also work with ancient versions of 
>>>> openwrt,
>>>> but in all the companies that I have worked at, it's proven to be 
>>>> less
>>>> ongoing work (and far less risk) to keep up with current versions 
>>>> than
>>>> it is to stick with old versions and then do periodic 'big jump'
>>>> upgrades.
>>>> it's like car maintinance, it seems easier to ignore your tires,
>>>> brakes, and oil changes, but the minimal cost of maintaining those
>>>> systems pays off in a big way over time
>>>> David Lang
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[David Lang]

On Sat, 14 Oct 2023, rjmcmahon wrote:

> On being unleashed, I think this applies to consumer electronics too. Not 
> sure why HDMI class cables will be needed. WiFi 7 is spec'd at 16 MIMO radios 
> at 45Gb/s per front end module. Add some hw compression/decompression, I 
> think it can carry even HDMI Utlra High Speed or 8K. And the content will 
> likely be coming from the cloud too, so the need for a short HDMI cable kinda 
> goes away.

until you have a few people in an area all trying to do the same thing, not they 
EACH need that much low-latency bandwith, and it just doesn't work well.

> Maybe I'm unique of being tired of having rats' nests of cables to connect 
> things. My thoughts are no more cables other than structured fiber and 
> structured AC which both are long lived, multiple decades or more, and hence 
> are a one and done type of spend.

It's much more practical to go to a single USB-C cable (power, video, etc) than 
it is to go completely wireless when you are stationary.

> I'm not a fan of PLC, mixing power and comm. I've installed AFCI circuit 
> breakers for all my family, including the in laws. These can trigger easily 
> when other signals are multiplexed.
>
> There were so many things that went wrong in The Bronx where 11 people died 
> including children. An AFCI breaker would likely have prevented that fire. 
> Working auto door closers would have helped. Providing heat pumps would have 
> helped too so kids didn't have to use electric resistive space heaters which 
> are terrible by my judgment.
>
> It's hard to believe that Notre Dame burned down too. We've got so 
> improvement to do on life support systems.

what's the retrofit cost vs the incrimental cost? (ROI timeframe), that's 
usually overlooked in these 'this technology is clearly better, everyone should 
be forced to switch to it' discussions.

(and don't get me started on Rent Control, common in NYC, which discourages 
investments by landlords)

David Lang

> https://en.wikipedia.org/wiki/2022_Bronx_apartment_fire
>
> Bob
>> Hi Bob,
>> 
>> 
>>> On Oct 13, 2023, at 19:20, rjmcmahon <rjmcmahon@rjmcmahon.com> wrote:
>>> 
>>> Hi Sebastian,
>>> 
>>> It was the ISP tech support over the phone. Trying to help install a home 
>>> network over the phone w/o a technician isn't easy.
>>
>> 	[SM] Ah, okay. I would never even think about calling my ISP when
>> considering changes to my home network (for one, I would rather
>> McGywer this, and also my ISP does not really offer that as a
>> servicedsdw), I guess different service offerings in different
>> countries.
>> 
>> 
>>> In many U.S. states, smoke detectors are required to be no more that 30' 
>>> apart, must be AC powered, battery backed up and must communicate with one 
>>> another. The smoke sensor needs to be replaced every ten years max.
>>
>> 	[SM] Intersting! Over here detectors are also mandatory (but no
>> distance or networking requirements, it is special rooms like bed
>> rooms that need to have one). Also over here no AC requirement.
>> 
>> 
>>> It's a good place to install remote radio heads, or even full blown APs, 
>>> for both internet access points and for life support sensors.
>>
>> 	[SM] I agree, and with an AC requirement powering such APs/radio
>> heads is not rocket science either, heck in a first iteration one
>> might even use PLC to bring data to the APs...
>> 
>> 
>>> 10G NRE spends stopped over a decade ago. Early adopters aren't likely 
>>> going to wire 10G over copper in their homes.
>>
>> 	[SM] Over here active 2.5 Gbps ethernet are just becoming cheap
>> enough for enthusiasts to switch over to, and 2.5 has the advantage of
>> operating well even over most cat5 wiring (few homes I know will push
>> anywhere close to the typical 100m copper ethernet limit, most will be
>> fine with < 30m).
>> 
>> 
>>> 100G only goes 4 meters so copper really isn't an option for future proof 
>>> comm cable throughout buildings.
>>
>> 	[SM] Indeed, but I am not 100% sure what use-case would justify going
>> 100Gbps in a typical home? Sure if one switches to fiber wiring and
>> 100Gbps is only marginally more expensive than 1 or 10 Gbps why not?
>> 
>>> Fiber to WiFi seems straight forward to me.
>>
>> 	[SM] This might be related to your professional background though? ;)
>> Just kidding, I think you are simply a few years ahead of the rest of
>> us, as you know what is in the pipeline.
>> 
>> 
>>> People don't want to be leashed to plugs so the last meters have to be 
>>> wireless.
>>
>> 	[SM] Yes and no. People did not bother about wiring office desks or
>> even smart TVs, but smart phones and tablets are a different kettle of
>> fish, as are laptops, that might be operated wired on the desk but
>> wireless in the rest of the house. I also note that more and more
>> laptops come without built in ethernet (personally I detest that, an
>> rj45 jack is not that thick that a laptop body can not be planned
>> around that, leaving some more room for e.g. NVMe sockets or simplify
>> cooling a bit, ultra-thin is IMHO not really in the end-users'
>> interest, but I digress).
>> 
>> 
>>> We need to standardized to the extent that we can on one wireless tech 
>>> (similar to Ethernet for wired) and a proposal is to use 802.11 since 
>>> that's selling in volume, driven by mobile hand sets.
>>
>> 	[SM] Sure 802.11 is likely to stay by virtue of being relatively
>> ubiquitous and by being generally already good enough for many use
>> cases (with road-maps for tackling more demanding use-cases, and I
>> very much include your fiwi proposal here).
>> 
>> 
>> 
>>> 
>>> Bob
>>>> Hi Bob,
>>>>> On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain 
>>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>> Hi David,
>>>>> The vendors I know don't roll their own os code either. The make their 
>>>>> own release still mostly based from Linux and they aren't tied to the 
>>>>> openwrt release process.
>>>>> I think GUIs on CPEs are the wrong direction. Consumer network equipment 
>>>>> does best when it's plug and play. Consumers don't have all the skills 
>>>>> needed to manage an in home packet network that includes wifi.
>>>> 	[SM] That is both true, and (currently?) unachievable. To run a
>>>> network connected to the internet securely requires to make a number
>>>> of policy decisions trading-off the required/desired connectivity
>>>> versus the cost in security (either cost as effort of maintaining
>>>> security or cost in an increase in attack surface).
>>>> 	The in-side the home situation, has IMHO drastically improved with
>>>> the availability of off-the-shelf mesh network gear from commercial
>>>> vendors, with easy to follow instructions and/or apps to find decent
>>>> AP placement.
>>>> 	For structured wiring, I would agree that requires both an unusual
>>>> skill set (even though doing structured wiring itself is not hard,
>>>> just doing it in a way that blends into an apartment without signaling
>>>> DIY-ness is more involved).
>>>>> I recently fixed a home network for my inlaws. It's a combo of 
>>>>> structured wire and WiFi APs. I purchased the latest equipment from 
>>>>> Amazon vs use the ISP provided equipment. I can do this reasonably well 
>>>>> because I'm familiar with the chips inside.
>>>>> The online tech support started with trepidation as he was concerned 
>>>>> that the home owner, i.e me, wasn't as skilled as the ISP technicians. 
>>>>> He suggested we schedule that but I said we were good to go w/o one.
>>>> 	[SM] What "online tech support"? From the AP vendor or from the ISP?
>>>> The latter might have a script recommending ISP technicians more for
>>>> commercial considerations than technical ones...
>>>>> He asked to speak to my father in law when we were all done. He told 
>>>>> him, "You're lucky to have a son in law that know what he's doing. My 
>>>>> techs aren't as good, and I really liked working with him too."
>>>>> I say this not to brag, as many on this list could do the equivalent, 
>>>>> but to show that we really need to train lots of technicians on things 
>>>>> like RF and structured wiring. Nobody should be "lucky" to get a quality 
>>>>> in home network.  We're not lucky to have a flush toilet anymore. This 
>>>>> stuff is too important to rely on luck.
>>>> 	[SM] Mmmh, that got me thinking, maybe we should think about always
>>>> running network wiring parallel to electric cables so each power
>>>> socket could easily house an ethernet plug as well... (or one per room
>>>> to keep the cost lower and avoid overly much "dark" copper)? Sort of
>>>> put this into the building codes/best current practice documents... (I
>>>> understand starting now, will still only solve the issue over many
>>>> decades, but at least we would be making some inroads; and speaking of
>>>> decades, maybe putting fiber there instead of copper might be a more
>>>> future-oriented approach)?
>>>>> Bob
>>>>> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>>> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>>> I don't know the numbers but a guess is that a majority of SoCs with 
>>>>> WiFi
>>>>> radios aren't based on openwrt.
>>>>> From what I've seen, the majority of APs out there are based on OpenWRT 
>>>>> or one
>>>>> of the competing open projects, very few roll their own OS from scratch
>>>>> I think many on this list use openwrt but
>>>>> that may not be representative of the actuals. Also, the trend is less 
>>>>> sw in
>>>>> a CPU forwarding plane and more hw, one day, linux at the CPEs may not 
>>>>> be
>>>>> needed at all (if we get to remote radio heads - though this is highly
>>>>> speculative.)
>>>>> that is countered by the trend to do more (fancier GUI, media center, 
>>>>> etc) The
>>>>> vendors all want to differentiate themselves, that's hard to do if it's 
>>>>> baked
>>>>> into the chips
>>>>> From my experience, sw is defined by the number & frequency of commits, 
>>>>> and
>>>>> of timeliness to issues more than a version number or compile date. So 
>>>>> the
>>>>> size and quality of the software staff can be informative.
>>>>> I'm more interested in mfg node process then the mfg location & date as 
>>>>> the
>>>>> node process gives an idea if the design is keeping up or not. Chips 
>>>>> designed
>>>>> in 2012 are woefully behind and consume too much energy and generate too 
>>>>> much
>>>>> heat. I think Intel provides this information on all its chips as an 
>>>>> example.
>>>>> I'm far less concerned about the chips than the software. Security holes 
>>>>> are far
>>>>> more likely in the software than the chips. The chips may limit the max
>>>>> performance of the devices, but the focus of this is on the security, 
>>>>> not the
>>>>> throughput or the power efficiency (I don't mind that extra info, but 
>>>>> what makes
>>>>> some device unsafe to use isn't the age of the chips, but the age of the
>>>>> software)
>>>>> David Lang
>>>>> Bob
>>>>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>>> There's also the concern about how do startups roll-out such a label for
>>>>> their tech in the early iteration phase? How do they afford to do the
>>>>> extra
>>>>> work for the label vs. a big company (does this become a regulatory 
>>>>> moat?)
>>>>> And let's say we have these labels. Will only consumers with the money 
>>>>> to
>>>>> purchase the more expensive equipment that has more privacy and security
>>>>> features buy that one - leaving those who cannot afford privacy and
>>>>> security bad alternatives?
>>>>> As far as security goes, I would argue that the easy answer is to ship
>>>>> a current version of openwrt instead of a forked, ancient version, and
>>>>> get their changes submitted upstream (or at least maintained against
>>>>> upstream). It's a different paradigm than they are used to, and right
>>>>> now the suppliers tend to also work with ancient versions of openwrt,
>>>>> but in all the companies that I have worked at, it's proven to be less
>>>>> ongoing work (and far less risk) to keep up with current versions than
>>>>> it is to stick with old versions and then do periodic 'big jump'
>>>>> upgrades.
>>>>> it's like car maintinance, it seems easier to ignore your tires,
>>>>> brakes, and oil changes, but the minimal cost of maintaining those
>>>>> systems pays off in a big way over time
>>>>> David Lang
>>>>> Nnagain mailing list
>>>>> Nnagain@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>> Nnagain mailing list
>>>>> Nnagain@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>> _______________________________________________
>>>>> Nnagain mailing list
>>>>> Nnagain@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>

Re: [NNagain] Internet Education for Non-technorati?

[Robert McMahon]

[-- Attachment #1: Type: text/plain, Size: 14502 bytes --]

It's $428 per ac ceiling mount hardwired device, no verticals. It's $503 per vertical for rg6 with patch n paint, internal walls only.

The asset value add for a rg6 jack is basically zero. The asset value add for whole home, life support capable, future proof,  low power, structured fiber & remote radio head is $2,857.

Staying ceiling mount helps a lot, no need for holes in the walls and no patch and paint.

All homes sold in the U.S. will have to do this per 2027 fire codes. The smart ones will connect the fiber fronthaul to capture the $2,857. Home networking is second behind in unit laundry for landlords. Rent increase for 100Gb/s point to point full duplex FiWi won't be known until after the $100M NRE spend to create the radio sticks.

No security vulnerabilities compared to those found in Linux computers. The radio stick is DSPs in transistors and optics. No general purpose CPU to exploit.

https://www.scmagazine.com/news/thousands-of-devices-exposed-to-critical-cisco-ios-xe-software-bug

Bob

On Oct 18, 2023, 5:40 PM, at 5:40 PM, David Lang <david@lang.hm> wrote:
>On Sat, 14 Oct 2023, rjmcmahon wrote:
>
>> On being unleashed, I think this applies to consumer electronics too.
>Not
>> sure why HDMI class cables will be needed. WiFi 7 is spec'd at 16
>MIMO radios
>> at 45Gb/s per front end module. Add some hw
>compression/decompression, I
>> think it can carry even HDMI Utlra High Speed or 8K. And the content
>will
>> likely be coming from the cloud too, so the need for a short HDMI
>cable kinda
>> goes away.
>
>until you have a few people in an area all trying to do the same thing,
>not they
>EACH need that much low-latency bandwith, and it just doesn't work
>well.
>
>> Maybe I'm unique of being tired of having rats' nests of cables to
>connect
>> things. My thoughts are no more cables other than structured fiber
>and
>> structured AC which both are long lived, multiple decades or more,
>and hence
>> are a one and done type of spend.
>
>It's much more practical to go to a single USB-C cable (power, video,
>etc) than
>it is to go completely wireless when you are stationary.
>
>> I'm not a fan of PLC, mixing power and comm. I've installed AFCI
>circuit
>> breakers for all my family, including the in laws. These can trigger
>easily
>> when other signals are multiplexed.
>>
>> There were so many things that went wrong in The Bronx where 11
>people died
>> including children. An AFCI breaker would likely have prevented that
>fire.
>> Working auto door closers would have helped. Providing heat pumps
>would have
>> helped too so kids didn't have to use electric resistive space
>heaters which
>> are terrible by my judgment.
>>
>> It's hard to believe that Notre Dame burned down too. We've got so
>> improvement to do on life support systems.
>
>what's the retrofit cost vs the incrimental cost? (ROI timeframe),
>that's
>usually overlooked in these 'this technology is clearly better,
>everyone should
>be forced to switch to it' discussions.
>
>(and don't get me started on Rent Control, common in NYC, which
>discourages
>investments by landlords)
>
>David Lang
>
>> https://en.wikipedia.org/wiki/2022_Bronx_apartment_fire
>>
>> Bob
>>> Hi Bob,
>>>
>>>
>>>> On Oct 13, 2023, at 19:20, rjmcmahon <rjmcmahon@rjmcmahon.com>
>wrote:
>>>>
>>>> Hi Sebastian,
>>>>
>>>> It was the ISP tech support over the phone. Trying to help install
>a home
>>>> network over the phone w/o a technician isn't easy.
>>>
>>> 	[SM] Ah, okay. I would never even think about calling my ISP when
>>> considering changes to my home network (for one, I would rather
>>> McGywer this, and also my ISP does not really offer that as a
>>> servicedsdw), I guess different service offerings in different
>>> countries.
>>>
>>>
>>>> In many U.S. states, smoke detectors are required to be no more
>that 30'
>>>> apart, must be AC powered, battery backed up and must communicate
>with one
>>>> another. The smoke sensor needs to be replaced every ten years max.
>>>
>>> 	[SM] Intersting! Over here detectors are also mandatory (but no
>>> distance or networking requirements, it is special rooms like bed
>>> rooms that need to have one). Also over here no AC requirement.
>>>
>>>
>>>> It's a good place to install remote radio heads, or even full blown
>APs,
>>>> for both internet access points and for life support sensors.
>>>
>>> 	[SM] I agree, and with an AC requirement powering such APs/radio
>>> heads is not rocket science either, heck in a first iteration one
>>> might even use PLC to bring data to the APs...
>>>
>>>
>>>> 10G NRE spends stopped over a decade ago. Early adopters aren't
>likely
>>>> going to wire 10G over copper in their homes.
>>>
>>> 	[SM] Over here active 2.5 Gbps ethernet are just becoming cheap
>>> enough for enthusiasts to switch over to, and 2.5 has the advantage
>of
>>> operating well even over most cat5 wiring (few homes I know will
>push
>>> anywhere close to the typical 100m copper ethernet limit, most will
>be
>>> fine with < 30m).
>>>
>>>
>>>> 100G only goes 4 meters so copper really isn't an option for future
>proof
>>>> comm cable throughout buildings.
>>>
>>> 	[SM] Indeed, but I am not 100% sure what use-case would justify
>going
>>> 100Gbps in a typical home? Sure if one switches to fiber wiring and
>>> 100Gbps is only marginally more expensive than 1 or 10 Gbps why not?
>>>
>>>> Fiber to WiFi seems straight forward to me.
>>>
>>> 	[SM] This might be related to your professional background though?
>;)
>>> Just kidding, I think you are simply a few years ahead of the rest
>of
>>> us, as you know what is in the pipeline.
>>>
>>> 
>>>> People don't want to be leashed to plugs so the last meters have to
>be
>>>> wireless.
>>>
>>> 	[SM] Yes and no. People did not bother about wiring office desks or
>>> even smart TVs, but smart phones and tablets are a different kettle
>of
>>> fish, as are laptops, that might be operated wired on the desk but
>>> wireless in the rest of the house. I also note that more and more
>>> laptops come without built in ethernet (personally I detest that, an
>>> rj45 jack is not that thick that a laptop body can not be planned
>>> around that, leaving some more room for e.g. NVMe sockets or
>simplify
>>> cooling a bit, ultra-thin is IMHO not really in the end-users'
>>> interest, but I digress).
>>>
>>>
>>>> We need to standardized to the extent that we can on one wireless
>tech
>>>> (similar to Ethernet for wired) and a proposal is to use 802.11
>since
>>>> that's selling in volume, driven by mobile hand sets.
>>>
>>> 	[SM] Sure 802.11 is likely to stay by virtue of being relatively
>>> ubiquitous and by being generally already good enough for many use
>>> cases (with road-maps for tackling more demanding use-cases, and I
>>> very much include your fiwi proposal here).
>>>
>>>
>>>
>>>>
>>>> Bob
>>>>> Hi Bob,
>>>>>> On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain
>>>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>>> Hi David,
>>>>>> The vendors I know don't roll their own os code either. The make
>their
>>>>>> own release still mostly based from Linux and they aren't tied to
>the
>>>>>> openwrt release process.
>>>>>> I think GUIs on CPEs are the wrong direction. Consumer network
>equipment
>>>>>> does best when it's plug and play. Consumers don't have all the
>skills
>>>>>> needed to manage an in home packet network that includes wifi.
>>>>> 	[SM] That is both true, and (currently?) unachievable. To run a
>>>>> network connected to the internet securely requires to make a
>number
>>>>> of policy decisions trading-off the required/desired connectivity
>>>>> versus the cost in security (either cost as effort of maintaining
>>>>> security or cost in an increase in attack surface).
>>>>> 	The in-side the home situation, has IMHO drastically improved
>with
>>>>> the availability of off-the-shelf mesh network gear from
>commercial
>>>>> vendors, with easy to follow instructions and/or apps to find
>decent
>>>>> AP placement.
>>>>> 	For structured wiring, I would agree that requires both an
>unusual
>>>>> skill set (even though doing structured wiring itself is not hard,
>>>>> just doing it in a way that blends into an apartment without
>signaling
>>>>> DIY-ness is more involved).
>>>>>> I recently fixed a home network for my inlaws. It's a combo of
>>>>>> structured wire and WiFi APs. I purchased the latest equipment
>from
>>>>>> Amazon vs use the ISP provided equipment. I can do this
>reasonably well
>>>>>> because I'm familiar with the chips inside.
>>>>>> The online tech support started with trepidation as he was
>concerned
>>>>>> that the home owner, i.e me, wasn't as skilled as the ISP
>technicians.
>>>>>> He suggested we schedule that but I said we were good to go w/o
>one.
>>>>> 	[SM] What "online tech support"? From the AP vendor or from the
>ISP?
>>>>> The latter might have a script recommending ISP technicians more
>for
>>>>> commercial considerations than technical ones...
>>>>>> He asked to speak to my father in law when we were all done. He
>told
>>>>>> him, "You're lucky to have a son in law that know what he's
>doing. My
>>>>>> techs aren't as good, and I really liked working with him too."
>>>>>> I say this not to brag, as many on this list could do the
>equivalent,
>>>>>> but to show that we really need to train lots of technicians on
>things
>>>>>> like RF and structured wiring. Nobody should be "lucky" to get a
>quality
>>>>>> in home network.  We're not lucky to have a flush toilet anymore.
>This
>>>>>> stuff is too important to rely on luck.
>>>>> 	[SM] Mmmh, that got me thinking, maybe we should think about
>always
>>>>> running network wiring parallel to electric cables so each power
>>>>> socket could easily house an ethernet plug as well... (or one per
>room
>>>>> to keep the cost lower and avoid overly much "dark" copper)? Sort
>of
>>>>> put this into the building codes/best current practice
>documents... (I
>>>>> understand starting now, will still only solve the issue over many
>>>>> decades, but at least we would be making some inroads; and
>speaking of
>>>>> decades, maybe putting fiber there instead of copper might be a
>more
>>>>> future-oriented approach)?
>>>>>> Bob
>>>>>> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>>>> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>>>> I don't know the numbers but a guess is that a majority of SoCs
>with
>>>>>> WiFi
>>>>>> radios aren't based on openwrt.
>>>>>> From what I've seen, the majority of APs out there are based on
>OpenWRT 
>>>>>> or one
>>>>>> of the competing open projects, very few roll their own OS from
>scratch
>>>>>> I think many on this list use openwrt but
>>>>>> that may not be representative of the actuals. Also, the trend is
>less 
>>>>>> sw in
>>>>>> a CPU forwarding plane and more hw, one day, linux at the CPEs
>may not
>>>>>> be
>>>>>> needed at all (if we get to remote radio heads - though this is
>highly
>>>>>> speculative.)
>>>>>> that is countered by the trend to do more (fancier GUI, media
>center,
>>>>>> etc) The
>>>>>> vendors all want to differentiate themselves, that's hard to do
>if it's
>>>>>> baked
>>>>>> into the chips
>>>>>> From my experience, sw is defined by the number & frequency of
>commits,
>>>>>> and
>>>>>> of timeliness to issues more than a version number or compile
>date. So
>>>>>> the
>>>>>> size and quality of the software staff can be informative.
>>>>>> I'm more interested in mfg node process then the mfg location &
>date as 
>>>>>> the
>>>>>> node process gives an idea if the design is keeping up or not.
>Chips
>>>>>> designed
>>>>>> in 2012 are woefully behind and consume too much energy and
>generate too
>>>>>> much
>>>>>> heat. I think Intel provides this information on all its chips as
>an
>>>>>> example.
>>>>>> I'm far less concerned about the chips than the software.
>Security holes
>>>>>> are far
>>>>>> more likely in the software than the chips. The chips may limit
>the max
>>>>>> performance of the devices, but the focus of this is on the
>security,
>>>>>> not the
>>>>>> throughput or the power efficiency (I don't mind that extra info,
>but
>>>>>> what makes
>>>>>> some device unsafe to use isn't the age of the chips, but the age
>of the
>>>>>> software)
>>>>>> David Lang
>>>>>> Bob
>>>>>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>>>> There's also the concern about how do startups roll-out such a
>label for
>>>>>> their tech in the early iteration phase? How do they afford to do
>the
>>>>>> extra
>>>>>> work for the label vs. a big company (does this become a
>regulatory
>>>>>> moat?)
>>>>>> And let's say we have these labels. Will only consumers with the
>money
>>>>>> to
>>>>>> purchase the more expensive equipment that has more privacy and
>security
>>>>>> features buy that one - leaving those who cannot afford privacy
>and
>>>>>> security bad alternatives?
>>>>>> As far as security goes, I would argue that the easy answer is to
>ship
>>>>>> a current version of openwrt instead of a forked, ancient
>version, and
>>>>>> get their changes submitted upstream (or at least maintained
>against
>>>>>> upstream). It's a different paradigm than they are used to, and
>right
>>>>>> now the suppliers tend to also work with ancient versions of
>openwrt,
>>>>>> but in all the companies that I have worked at, it's proven to be
>less
>>>>>> ongoing work (and far less risk) to keep up with current versions
>than
>>>>>> it is to stick with old versions and then do periodic 'big jump'
>>>>>> upgrades.
>>>>>> it's like car maintinance, it seems easier to ignore your tires,
>>>>>> brakes, and oil changes, but the minimal cost of maintaining
>those
>>>>>> systems pays off in a big way over time
>>>>>> David Lang
>>>>>> Nnagain mailing list
>>>>>> Nnagain@lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> Nnagain mailing list
>>>>>> Nnagain@lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> _______________________________________________
>>>>>> Nnagain mailing list
>>>>>> Nnagain@lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>

[-- Attachment #2: Type: text/html, Size: 17140 bytes --]

Re: [NNagain] Internet Education for Non-technorati?

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 14891 bytes --]

On Wed, 18 Oct 2023, Robert McMahon wrote:

> It's $428 per ac ceiling mount hardwired device, no verticals. It's $503 per vertical for rg6 with patch n paint, internal walls only.
>
> The asset value add for a rg6 jack is basically zero. The asset value add for whole home, life support capable, future proof,  low power, structured fiber & remote radio head is $2,857.
>
> Staying ceiling mount helps a lot, no need for holes in the walls and no patch and paint.
>
> All homes sold in the U.S. will have to do this per 2027 fire codes. The smart ones will connect the fiber fronthaul to capture the $2,857. Home networking is second behind in unit laundry for landlords. Rent increase for 100Gb/s point to point full duplex FiWi won't be known until after the $100M NRE spend to create the radio sticks.

No, all NEW homes built will need it, old homes do not need to be retrofitted. 
This is normal for many things.

It's cheap to do this sort of thing when a house is built, it's FAR more 
expensive to retrofit a house.

David Lang

> No security vulnerabilities compared to those found in Linux computers. The radio stick is DSPs in transistors and optics. No general purpose CPU to exploit.
>
> https://www.scmagazine.com/news/thousands-of-devices-exposed-to-critical-cisco-ios-xe-software-bug
>
> Bob
>
> On Oct 18, 2023, 5:40 PM, at 5:40 PM, David Lang <david@lang.hm> wrote:
>> On Sat, 14 Oct 2023, rjmcmahon wrote:
>>
>>> On being unleashed, I think this applies to consumer electronics too.
>> Not
>>> sure why HDMI class cables will be needed. WiFi 7 is spec'd at 16
>> MIMO radios
>>> at 45Gb/s per front end module. Add some hw
>> compression/decompression, I
>>> think it can carry even HDMI Utlra High Speed or 8K. And the content
>> will
>>> likely be coming from the cloud too, so the need for a short HDMI
>> cable kinda
>>> goes away.
>>
>> until you have a few people in an area all trying to do the same thing,
>> not they
>> EACH need that much low-latency bandwith, and it just doesn't work
>> well.
>>
>>> Maybe I'm unique of being tired of having rats' nests of cables to
>> connect
>>> things. My thoughts are no more cables other than structured fiber
>> and
>>> structured AC which both are long lived, multiple decades or more,
>> and hence
>>> are a one and done type of spend.
>>
>> It's much more practical to go to a single USB-C cable (power, video,
>> etc) than
>> it is to go completely wireless when you are stationary.
>>
>>> I'm not a fan of PLC, mixing power and comm. I've installed AFCI
>> circuit
>>> breakers for all my family, including the in laws. These can trigger
>> easily
>>> when other signals are multiplexed.
>>>
>>> There were so many things that went wrong in The Bronx where 11
>> people died
>>> including children. An AFCI breaker would likely have prevented that
>> fire.
>>> Working auto door closers would have helped. Providing heat pumps
>> would have
>>> helped too so kids didn't have to use electric resistive space
>> heaters which
>>> are terrible by my judgment.
>>>
>>> It's hard to believe that Notre Dame burned down too. We've got so
>>> improvement to do on life support systems.
>>
>> what's the retrofit cost vs the incrimental cost? (ROI timeframe),
>> that's
>> usually overlooked in these 'this technology is clearly better,
>> everyone should
>> be forced to switch to it' discussions.
>>
>> (and don't get me started on Rent Control, common in NYC, which
>> discourages
>> investments by landlords)
>>
>> David Lang
>>
>>> https://en.wikipedia.org/wiki/2022_Bronx_apartment_fire
>>>
>>> Bob
>>>> Hi Bob,
>>>>
>>>>
>>>>> On Oct 13, 2023, at 19:20, rjmcmahon <rjmcmahon@rjmcmahon.com>
>> wrote:
>>>>>
>>>>> Hi Sebastian,
>>>>>
>>>>> It was the ISP tech support over the phone. Trying to help install
>> a home
>>>>> network over the phone w/o a technician isn't easy.
>>>>
>>>> 	[SM] Ah, okay. I would never even think about calling my ISP when
>>>> considering changes to my home network (for one, I would rather
>>>> McGywer this, and also my ISP does not really offer that as a
>>>> servicedsdw), I guess different service offerings in different
>>>> countries.
>>>>
>>>>
>>>>> In many U.S. states, smoke detectors are required to be no more
>> that 30'
>>>>> apart, must be AC powered, battery backed up and must communicate
>> with one
>>>>> another. The smoke sensor needs to be replaced every ten years max.
>>>>
>>>> 	[SM] Intersting! Over here detectors are also mandatory (but no
>>>> distance or networking requirements, it is special rooms like bed
>>>> rooms that need to have one). Also over here no AC requirement.
>>>>
>>>>
>>>>> It's a good place to install remote radio heads, or even full blown
>> APs,
>>>>> for both internet access points and for life support sensors.
>>>>
>>>> 	[SM] I agree, and with an AC requirement powering such APs/radio
>>>> heads is not rocket science either, heck in a first iteration one
>>>> might even use PLC to bring data to the APs...
>>>>
>>>>
>>>>> 10G NRE spends stopped over a decade ago. Early adopters aren't
>> likely
>>>>> going to wire 10G over copper in their homes.
>>>>
>>>> 	[SM] Over here active 2.5 Gbps ethernet are just becoming cheap
>>>> enough for enthusiasts to switch over to, and 2.5 has the advantage
>> of
>>>> operating well even over most cat5 wiring (few homes I know will
>> push
>>>> anywhere close to the typical 100m copper ethernet limit, most will
>> be
>>>> fine with < 30m).
>>>>
>>>>
>>>>> 100G only goes 4 meters so copper really isn't an option for future
>> proof
>>>>> comm cable throughout buildings.
>>>>
>>>> 	[SM] Indeed, but I am not 100% sure what use-case would justify
>> going
>>>> 100Gbps in a typical home? Sure if one switches to fiber wiring and
>>>> 100Gbps is only marginally more expensive than 1 or 10 Gbps why not?
>>>>
>>>>> Fiber to WiFi seems straight forward to me.
>>>>
>>>> 	[SM] This might be related to your professional background though?
>> ;)
>>>> Just kidding, I think you are simply a few years ahead of the rest
>> of
>>>> us, as you know what is in the pipeline.
>>>>
>>>>
>>>>> People don't want to be leashed to plugs so the last meters have to
>> be
>>>>> wireless.
>>>>
>>>> 	[SM] Yes and no. People did not bother about wiring office desks or
>>>> even smart TVs, but smart phones and tablets are a different kettle
>> of
>>>> fish, as are laptops, that might be operated wired on the desk but
>>>> wireless in the rest of the house. I also note that more and more
>>>> laptops come without built in ethernet (personally I detest that, an
>>>> rj45 jack is not that thick that a laptop body can not be planned
>>>> around that, leaving some more room for e.g. NVMe sockets or
>> simplify
>>>> cooling a bit, ultra-thin is IMHO not really in the end-users'
>>>> interest, but I digress).
>>>>
>>>>
>>>>> We need to standardized to the extent that we can on one wireless
>> tech
>>>>> (similar to Ethernet for wired) and a proposal is to use 802.11
>> since
>>>>> that's selling in volume, driven by mobile hand sets.
>>>>
>>>> 	[SM] Sure 802.11 is likely to stay by virtue of being relatively
>>>> ubiquitous and by being generally already good enough for many use
>>>> cases (with road-maps for tackling more demanding use-cases, and I
>>>> very much include your fiwi proposal here).
>>>>
>>>>
>>>>
>>>>>
>>>>> Bob
>>>>>> Hi Bob,
>>>>>>> On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain
>>>>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>>>> Hi David,
>>>>>>> The vendors I know don't roll their own os code either. The make
>> their
>>>>>>> own release still mostly based from Linux and they aren't tied to
>> the
>>>>>>> openwrt release process.
>>>>>>> I think GUIs on CPEs are the wrong direction. Consumer network
>> equipment
>>>>>>> does best when it's plug and play. Consumers don't have all the
>> skills
>>>>>>> needed to manage an in home packet network that includes wifi.
>>>>>> 	[SM] That is both true, and (currently?) unachievable. To run a
>>>>>> network connected to the internet securely requires to make a
>> number
>>>>>> of policy decisions trading-off the required/desired connectivity
>>>>>> versus the cost in security (either cost as effort of maintaining
>>>>>> security or cost in an increase in attack surface).
>>>>>> 	The in-side the home situation, has IMHO drastically improved
>> with
>>>>>> the availability of off-the-shelf mesh network gear from
>> commercial
>>>>>> vendors, with easy to follow instructions and/or apps to find
>> decent
>>>>>> AP placement.
>>>>>> 	For structured wiring, I would agree that requires both an
>> unusual
>>>>>> skill set (even though doing structured wiring itself is not hard,
>>>>>> just doing it in a way that blends into an apartment without
>> signaling
>>>>>> DIY-ness is more involved).
>>>>>>> I recently fixed a home network for my inlaws. It's a combo of
>>>>>>> structured wire and WiFi APs. I purchased the latest equipment
>> from
>>>>>>> Amazon vs use the ISP provided equipment. I can do this
>> reasonably well
>>>>>>> because I'm familiar with the chips inside.
>>>>>>> The online tech support started with trepidation as he was
>> concerned
>>>>>>> that the home owner, i.e me, wasn't as skilled as the ISP
>> technicians.
>>>>>>> He suggested we schedule that but I said we were good to go w/o
>> one.
>>>>>> 	[SM] What "online tech support"? From the AP vendor or from the
>> ISP?
>>>>>> The latter might have a script recommending ISP technicians more
>> for
>>>>>> commercial considerations than technical ones...
>>>>>>> He asked to speak to my father in law when we were all done. He
>> told
>>>>>>> him, "You're lucky to have a son in law that know what he's
>> doing. My
>>>>>>> techs aren't as good, and I really liked working with him too."
>>>>>>> I say this not to brag, as many on this list could do the
>> equivalent,
>>>>>>> but to show that we really need to train lots of technicians on
>> things
>>>>>>> like RF and structured wiring. Nobody should be "lucky" to get a
>> quality
>>>>>>> in home network.  We're not lucky to have a flush toilet anymore.
>> This
>>>>>>> stuff is too important to rely on luck.
>>>>>> 	[SM] Mmmh, that got me thinking, maybe we should think about
>> always
>>>>>> running network wiring parallel to electric cables so each power
>>>>>> socket could easily house an ethernet plug as well... (or one per
>> room
>>>>>> to keep the cost lower and avoid overly much "dark" copper)? Sort
>> of
>>>>>> put this into the building codes/best current practice
>> documents... (I
>>>>>> understand starting now, will still only solve the issue over many
>>>>>> decades, but at least we would be making some inroads; and
>> speaking of
>>>>>> decades, maybe putting fiber there instead of copper might be a
>> more
>>>>>> future-oriented approach)?
>>>>>>> Bob
>>>>>>> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>>>>> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>>>>> I don't know the numbers but a guess is that a majority of SoCs
>> with
>>>>>>> WiFi
>>>>>>> radios aren't based on openwrt.
>>>>>>> From what I've seen, the majority of APs out there are based on
>> OpenWRT
>>>>>>> or one
>>>>>>> of the competing open projects, very few roll their own OS from
>> scratch
>>>>>>> I think many on this list use openwrt but
>>>>>>> that may not be representative of the actuals. Also, the trend is
>> less
>>>>>>> sw in
>>>>>>> a CPU forwarding plane and more hw, one day, linux at the CPEs
>> may not
>>>>>>> be
>>>>>>> needed at all (if we get to remote radio heads - though this is
>> highly
>>>>>>> speculative.)
>>>>>>> that is countered by the trend to do more (fancier GUI, media
>> center,
>>>>>>> etc) The
>>>>>>> vendors all want to differentiate themselves, that's hard to do
>> if it's
>>>>>>> baked
>>>>>>> into the chips
>>>>>>> From my experience, sw is defined by the number & frequency of
>> commits,
>>>>>>> and
>>>>>>> of timeliness to issues more than a version number or compile
>> date. So
>>>>>>> the
>>>>>>> size and quality of the software staff can be informative.
>>>>>>> I'm more interested in mfg node process then the mfg location &
>> date as
>>>>>>> the
>>>>>>> node process gives an idea if the design is keeping up or not.
>> Chips
>>>>>>> designed
>>>>>>> in 2012 are woefully behind and consume too much energy and
>> generate too
>>>>>>> much
>>>>>>> heat. I think Intel provides this information on all its chips as
>> an
>>>>>>> example.
>>>>>>> I'm far less concerned about the chips than the software.
>> Security holes
>>>>>>> are far
>>>>>>> more likely in the software than the chips. The chips may limit
>> the max
>>>>>>> performance of the devices, but the focus of this is on the
>> security,
>>>>>>> not the
>>>>>>> throughput or the power efficiency (I don't mind that extra info,
>> but
>>>>>>> what makes
>>>>>>> some device unsafe to use isn't the age of the chips, but the age
>> of the
>>>>>>> software)
>>>>>>> David Lang
>>>>>>> Bob
>>>>>>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>>>>> There's also the concern about how do startups roll-out such a
>> label for
>>>>>>> their tech in the early iteration phase? How do they afford to do
>> the
>>>>>>> extra
>>>>>>> work for the label vs. a big company (does this become a
>> regulatory
>>>>>>> moat?)
>>>>>>> And let's say we have these labels. Will only consumers with the
>> money
>>>>>>> to
>>>>>>> purchase the more expensive equipment that has more privacy and
>> security
>>>>>>> features buy that one - leaving those who cannot afford privacy
>> and
>>>>>>> security bad alternatives?
>>>>>>> As far as security goes, I would argue that the easy answer is to
>> ship
>>>>>>> a current version of openwrt instead of a forked, ancient
>> version, and
>>>>>>> get their changes submitted upstream (or at least maintained
>> against
>>>>>>> upstream). It's a different paradigm than they are used to, and
>> right
>>>>>>> now the suppliers tend to also work with ancient versions of
>> openwrt,
>>>>>>> but in all the companies that I have worked at, it's proven to be
>> less
>>>>>>> ongoing work (and far less risk) to keep up with current versions
>> than
>>>>>>> it is to stick with old versions and then do periodic 'big jump'
>>>>>>> upgrades.
>>>>>>> it's like car maintinance, it seems easier to ignore your tires,
>>>>>>> brakes, and oil changes, but the minimal cost of maintaining
>> those
>>>>>>> systems pays off in a big way over time
>>>>>>> David Lang
>>>>>>> Nnagain mailing list
>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>>> Nnagain mailing list
>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>>> _______________________________________________
>>>>>>> Nnagain mailing list
>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>
>

Re: [NNagain] Internet Education for Non-technorati?

[Robert McMahon]

[-- Attachment #1: Type: text/plain, Size: 16095 bytes --]

Retrofit is trivial. It's all in the attic. A romex splice is about $53. Verticals aren't required.

Many states are mandating per each sale. I had to do this in Boston historic district. No grandfather. My fire hurts the entire street

⁣Bob

On Oct 18, 2023, 7:05 PM, at 7:05 PM, David Lang <david@lang.hm> wrote:
>On Wed, 18 Oct 2023, Robert McMahon wrote:
>
>> It's $428 per ac ceiling mount hardwired device, no verticals. It's
>$503 per vertical for rg6 with patch n paint, internal walls only.
>>
>> The asset value add for a rg6 jack is basically zero. The asset value
>add for whole home, life support capable, future proof,  low power,
>structured fiber & remote radio head is $2,857.
>>
>> Staying ceiling mount helps a lot, no need for holes in the walls and
>no patch and paint.
>>
>> All homes sold in the U.S. will have to do this per 2027 fire codes.
>The smart ones will connect the fiber fronthaul to capture the $2,857.
>Home networking is second behind in unit laundry for landlords. Rent
>increase for 100Gb/s point to point full duplex FiWi won't be known
>until after the $100M NRE spend to create the radio sticks.
>
>No, all NEW homes built will need it, old homes do not need to be
>retrofitted.
>This is normal for many things.
>
>It's cheap to do this sort of thing when a house is built, it's FAR
>more
>expensive to retrofit a house.
>
>David Lang
>
>> No security vulnerabilities compared to those found in Linux
>computers. The radio stick is DSPs in transistors and optics. No
>general purpose CPU to exploit.
>>
>>
>https://www.scmagazine.com/news/thousands-of-devices-exposed-to-critical-cisco-ios-xe-software-bug
>>
>> Bob
>>
>> On Oct 18, 2023, 5:40 PM, at 5:40 PM, David Lang <david@lang.hm>
>wrote:
>>> On Sat, 14 Oct 2023, rjmcmahon wrote:
>>>
>>>> On being unleashed, I think this applies to consumer electronics
>too.
>>> Not
>>>> sure why HDMI class cables will be needed. WiFi 7 is spec'd at 16
>>> MIMO radios
>>>> at 45Gb/s per front end module. Add some hw
>>> compression/decompression, I
>>>> think it can carry even HDMI Utlra High Speed or 8K. And the
>content
>>> will
>>>> likely be coming from the cloud too, so the need for a short HDMI
>>> cable kinda
>>>> goes away.
>>>
>>> until you have a few people in an area all trying to do the same
>thing,
>>> not they
>>> EACH need that much low-latency bandwith, and it just doesn't work
>>> well.
>>>
>>>> Maybe I'm unique of being tired of having rats' nests of cables to
>>> connect
>>>> things. My thoughts are no more cables other than structured fiber
>>> and
>>>> structured AC which both are long lived, multiple decades or more,
>>> and hence
>>>> are a one and done type of spend.
>>>
>>> It's much more practical to go to a single USB-C cable (power,
>video,
>>> etc) than
>>> it is to go completely wireless when you are stationary.
>>>
>>>> I'm not a fan of PLC, mixing power and comm. I've installed AFCI
>>> circuit
>>>> breakers for all my family, including the in laws. These can
>trigger
>>> easily
>>>> when other signals are multiplexed.
>>>>
>>>> There were so many things that went wrong in The Bronx where 11
>>> people died
>>>> including children. An AFCI breaker would likely have prevented
>that
>>> fire.
>>>> Working auto door closers would have helped. Providing heat pumps
>>> would have
>>>> helped too so kids didn't have to use electric resistive space
>>> heaters which
>>>> are terrible by my judgment.
>>>>
>>>> It's hard to believe that Notre Dame burned down too. We've got so
>>>> improvement to do on life support systems.
>>>
>>> what's the retrofit cost vs the incrimental cost? (ROI timeframe),
>>> that's
>>> usually overlooked in these 'this technology is clearly better,
>>> everyone should
>>> be forced to switch to it' discussions.
>>>
>>> (and don't get me started on Rent Control, common in NYC, which
>>> discourages
>>> investments by landlords)
>>>
>>> David Lang
>>>
>>>> https://en.wikipedia.org/wiki/2022_Bronx_apartment_fire
>>>>
>>>> Bob
>>>>> Hi Bob,
>>>>>
>>>>>
>>>>>> On Oct 13, 2023, at 19:20, rjmcmahon <rjmcmahon@rjmcmahon.com>
>>> wrote:
>>>>>>
>>>>>> Hi Sebastian,
>>>>>>
>>>>>> It was the ISP tech support over the phone. Trying to help
>install
>>> a home
>>>>>> network over the phone w/o a technician isn't easy.
>>>>>
>>>>> 	[SM] Ah, okay. I would never even think about calling my ISP when
>>>>> considering changes to my home network (for one, I would rather
>>>>> McGywer this, and also my ISP does not really offer that as a
>>>>> servicedsdw), I guess different service offerings in different
>>>>> countries.
>>>>>
>>>>>
>>>>>> In many U.S. states, smoke detectors are required to be no more
>>> that 30'
>>>>>> apart, must be AC powered, battery backed up and must communicate
>>> with one
>>>>>> another. The smoke sensor needs to be replaced every ten years
>max.
>>>>>
>>>>> 	[SM] Intersting! Over here detectors are also mandatory (but no
>>>>> distance or networking requirements, it is special rooms like bed
>>>>> rooms that need to have one). Also over here no AC requirement.
>>>>>
>>>>>
>>>>>> It's a good place to install remote radio heads, or even full
>blown
>>> APs,
>>>>>> for both internet access points and for life support sensors.
>>>>>
>>>>> 	[SM] I agree, and with an AC requirement powering such APs/radio
>>>>> heads is not rocket science either, heck in a first iteration one
>>>>> might even use PLC to bring data to the APs...
>>>>>
>>>>>
>>>>>> 10G NRE spends stopped over a decade ago. Early adopters aren't
>>> likely
>>>>>> going to wire 10G over copper in their homes.
>>>>>
>>>>> 	[SM] Over here active 2.5 Gbps ethernet are just becoming cheap
>>>>> enough for enthusiasts to switch over to, and 2.5 has the
>advantage
>>> of
>>>>> operating well even over most cat5 wiring (few homes I know will
>>> push
>>>>> anywhere close to the typical 100m copper ethernet limit, most
>will
>>> be
>>>>> fine with < 30m).
>>>>>
>>>>>
>>>>>> 100G only goes 4 meters so copper really isn't an option for
>future
>>> proof
>>>>>> comm cable throughout buildings.
>>>>>
>>>>> 	[SM] Indeed, but I am not 100% sure what use-case would justify
>>> going
>>>>> 100Gbps in a typical home? Sure if one switches to fiber wiring
>and
>>>>> 100Gbps is only marginally more expensive than 1 or 10 Gbps why
>not?
>>>>>
>>>>>> Fiber to WiFi seems straight forward to me.
>>>>>
>>>>> 	[SM] This might be related to your professional background
>though?
>>> ;)
>>>>> Just kidding, I think you are simply a few years ahead of the rest
>>> of
>>>>> us, as you know what is in the pipeline.
>>>>>
>>>>>
>>>>>> People don't want to be leashed to plugs so the last meters have
>to
>>> be
>>>>>> wireless.
>>>>>
>>>>> 	[SM] Yes and no. People did not bother about wiring office desks
>or
>>>>> even smart TVs, but smart phones and tablets are a different
>kettle
>>> of
>>>>> fish, as are laptops, that might be operated wired on the desk but
>>>>> wireless in the rest of the house. I also note that more and more
>>>>> laptops come without built in ethernet (personally I detest that,
>an
>>>>> rj45 jack is not that thick that a laptop body can not be planned
>>>>> around that, leaving some more room for e.g. NVMe sockets or
>>> simplify
>>>>> cooling a bit, ultra-thin is IMHO not really in the end-users'
>>>>> interest, but I digress).
>>>>>
>>>>>
>>>>>> We need to standardized to the extent that we can on one wireless
>>> tech
>>>>>> (similar to Ethernet for wired) and a proposal is to use 802.11
>>> since
>>>>>> that's selling in volume, driven by mobile hand sets.
>>>>>
>>>>> 	[SM] Sure 802.11 is likely to stay by virtue of being relatively
>>>>> ubiquitous and by being generally already good enough for many use
>>>>> cases (with road-maps for tackling more demanding use-cases, and I
>>>>> very much include your fiwi proposal here).
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Bob
>>>>>>> Hi Bob,
>>>>>>>> On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain
>>>>>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>>>>> Hi David,
>>>>>>>> The vendors I know don't roll their own os code either. The
>make
>>> their
>>>>>>>> own release still mostly based from Linux and they aren't tied
>to
>>> the
>>>>>>>> openwrt release process.
>>>>>>>> I think GUIs on CPEs are the wrong direction. Consumer network
>>> equipment
>>>>>>>> does best when it's plug and play. Consumers don't have all the
>>> skills
>>>>>>>> needed to manage an in home packet network that includes wifi.
>>>>>>> 	[SM] That is both true, and (currently?) unachievable. To run a
>>>>>>> network connected to the internet securely requires to make a
>>> number
>>>>>>> of policy decisions trading-off the required/desired
>connectivity
>>>>>>> versus the cost in security (either cost as effort of
>maintaining
>>>>>>> security or cost in an increase in attack surface).
>>>>>>> 	The in-side the home situation, has IMHO drastically improved
>>> with
>>>>>>> the availability of off-the-shelf mesh network gear from
>>> commercial
>>>>>>> vendors, with easy to follow instructions and/or apps to find
>>> decent
>>>>>>> AP placement.
>>>>>>> 	For structured wiring, I would agree that requires both an
>>> unusual
>>>>>>> skill set (even though doing structured wiring itself is not
>hard,
>>>>>>> just doing it in a way that blends into an apartment without
>>> signaling
>>>>>>> DIY-ness is more involved).
>>>>>>>> I recently fixed a home network for my inlaws. It's a combo of
>>>>>>>> structured wire and WiFi APs. I purchased the latest equipment
>>> from
>>>>>>>> Amazon vs use the ISP provided equipment. I can do this
>>> reasonably well
>>>>>>>> because I'm familiar with the chips inside.
>>>>>>>> The online tech support started with trepidation as he was
>>> concerned
>>>>>>>> that the home owner, i.e me, wasn't as skilled as the ISP
>>> technicians.
>>>>>>>> He suggested we schedule that but I said we were good to go w/o
>>> one.
>>>>>>> 	[SM] What "online tech support"? From the AP vendor or from the
>>> ISP?
>>>>>>> The latter might have a script recommending ISP technicians more
>>> for
>>>>>>> commercial considerations than technical ones...
>>>>>>>> He asked to speak to my father in law when we were all done. He
>>> told
>>>>>>>> him, "You're lucky to have a son in law that know what he's
>>> doing. My
>>>>>>>> techs aren't as good, and I really liked working with him too."
>>>>>>>> I say this not to brag, as many on this list could do the
>>> equivalent,
>>>>>>>> but to show that we really need to train lots of technicians on
>>> things
>>>>>>>> like RF and structured wiring. Nobody should be "lucky" to get
>a
>>> quality
>>>>>>>> in home network.  We're not lucky to have a flush toilet
>anymore.
>>> This
>>>>>>>> stuff is too important to rely on luck.
>>>>>>> 	[SM] Mmmh, that got me thinking, maybe we should think about
>>> always
>>>>>>> running network wiring parallel to electric cables so each power
>>>>>>> socket could easily house an ethernet plug as well... (or one
>per
>>> room
>>>>>>> to keep the cost lower and avoid overly much "dark" copper)?
>Sort
>>> of
>>>>>>> put this into the building codes/best current practice
>>> documents... (I
>>>>>>> understand starting now, will still only solve the issue over
>many
>>>>>>> decades, but at least we would be making some inroads; and
>>> speaking of
>>>>>>> decades, maybe putting fiber there instead of copper might be a
>>> more
>>>>>>> future-oriented approach)?
>>>>>>>> Bob
>>>>>>>> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>>>>>> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>>>>>> I don't know the numbers but a guess is that a majority of SoCs
>>> with
>>>>>>>> WiFi
>>>>>>>> radios aren't based on openwrt.
>>>>>>>> From what I've seen, the majority of APs out there are based on
>>> OpenWRT
>>>>>>>> or one
>>>>>>>> of the competing open projects, very few roll their own OS from
>>> scratch
>>>>>>>> I think many on this list use openwrt but
>>>>>>>> that may not be representative of the actuals. Also, the trend
>is
>>> less
>>>>>>>> sw in
>>>>>>>> a CPU forwarding plane and more hw, one day, linux at the CPEs
>>> may not
>>>>>>>> be
>>>>>>>> needed at all (if we get to remote radio heads - though this is
>>> highly
>>>>>>>> speculative.)
>>>>>>>> that is countered by the trend to do more (fancier GUI, media
>>> center,
>>>>>>>> etc) The
>>>>>>>> vendors all want to differentiate themselves, that's hard to do
>>> if it's
>>>>>>>> baked
>>>>>>>> into the chips
>>>>>>>> From my experience, sw is defined by the number & frequency of
>>> commits,
>>>>>>>> and
>>>>>>>> of timeliness to issues more than a version number or compile
>>> date. So
>>>>>>>> the
>>>>>>>> size and quality of the software staff can be informative.
>>>>>>>> I'm more interested in mfg node process then the mfg location &
>>> date as
>>>>>>>> the
>>>>>>>> node process gives an idea if the design is keeping up or not.
>>> Chips
>>>>>>>> designed
>>>>>>>> in 2012 are woefully behind and consume too much energy and
>>> generate too
>>>>>>>> much
>>>>>>>> heat. I think Intel provides this information on all its chips
>as
>>> an
>>>>>>>> example.
>>>>>>>> I'm far less concerned about the chips than the software.
>>> Security holes
>>>>>>>> are far
>>>>>>>> more likely in the software than the chips. The chips may limit
>>> the max
>>>>>>>> performance of the devices, but the focus of this is on the
>>> security,
>>>>>>>> not the
>>>>>>>> throughput or the power efficiency (I don't mind that extra
>info,
>>> but
>>>>>>>> what makes
>>>>>>>> some device unsafe to use isn't the age of the chips, but the
>age
>>> of the
>>>>>>>> software)
>>>>>>>> David Lang
>>>>>>>> Bob
>>>>>>>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>>>>>> There's also the concern about how do startups roll-out such a
>>> label for
>>>>>>>> their tech in the early iteration phase? How do they afford to
>do
>>> the
>>>>>>>> extra
>>>>>>>> work for the label vs. a big company (does this become a
>>> regulatory
>>>>>>>> moat?)
>>>>>>>> And let's say we have these labels. Will only consumers with
>the
>>> money
>>>>>>>> to
>>>>>>>> purchase the more expensive equipment that has more privacy and
>>> security
>>>>>>>> features buy that one - leaving those who cannot afford privacy
>>> and
>>>>>>>> security bad alternatives?
>>>>>>>> As far as security goes, I would argue that the easy answer is
>to
>>> ship
>>>>>>>> a current version of openwrt instead of a forked, ancient
>>> version, and
>>>>>>>> get their changes submitted upstream (or at least maintained
>>> against
>>>>>>>> upstream). It's a different paradigm than they are used to, and
>>> right
>>>>>>>> now the suppliers tend to also work with ancient versions of
>>> openwrt,
>>>>>>>> but in all the companies that I have worked at, it's proven to
>be
>>> less
>>>>>>>> ongoing work (and far less risk) to keep up with current
>versions
>>> than
>>>>>>>> it is to stick with old versions and then do periodic 'big
>jump'
>>>>>>>> upgrades.
>>>>>>>> it's like car maintinance, it seems easier to ignore your
>tires,
>>>>>>>> brakes, and oil changes, but the minimal cost of maintaining
>>> those
>>>>>>>> systems pays off in a big way over time
>>>>>>>> David Lang
>>>>>>>> Nnagain mailing list
>>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>>>> Nnagain mailing list
>>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>>>> _______________________________________________
>>>>>>>> Nnagain mailing list
>>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>
>>

[-- Attachment #2: Type: text/html, Size: 67952 bytes --]

Re: [NNagain] Internet Education for Non-technorati?

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 16576 bytes --]

assuming a single floor house with lose insulation in the attic

now look at a multi-story place where there isn't an attic, or one with trusses 
so that moving around the attic is hard, or a SIP cealing, cathedral cealings, 
etc.

but my initial comment on ROI and refitting cost was actually directed at the 
proposal to make heat pump retrofits mandatory.

David Lang

On Wed, 18 Oct 2023, Robert McMahon wrote:

> Retrofit is trivial. It's all in the attic. A romex splice is about $53. Verticals aren't required.
>
> Many states are mandating per each sale. I had to do this in Boston historic district. No grandfather. My fire hurts the entire street
>
> ⁣Bob
>
> On Oct 18, 2023, 7:05 PM, at 7:05 PM, David Lang <david@lang.hm> wrote:
>> On Wed, 18 Oct 2023, Robert McMahon wrote:
>>
>>> It's $428 per ac ceiling mount hardwired device, no verticals. It's
>> $503 per vertical for rg6 with patch n paint, internal walls only.
>>>
>>> The asset value add for a rg6 jack is basically zero. The asset value
>> add for whole home, life support capable, future proof,  low power,
>> structured fiber & remote radio head is $2,857.
>>>
>>> Staying ceiling mount helps a lot, no need for holes in the walls and
>> no patch and paint.
>>>
>>> All homes sold in the U.S. will have to do this per 2027 fire codes.
>> The smart ones will connect the fiber fronthaul to capture the $2,857.
>> Home networking is second behind in unit laundry for landlords. Rent
>> increase for 100Gb/s point to point full duplex FiWi won't be known
>> until after the $100M NRE spend to create the radio sticks.
>>
>> No, all NEW homes built will need it, old homes do not need to be
>> retrofitted.
>> This is normal for many things.
>>
>> It's cheap to do this sort of thing when a house is built, it's FAR
>> more
>> expensive to retrofit a house.
>>
>> David Lang
>>
>>> No security vulnerabilities compared to those found in Linux
>> computers. The radio stick is DSPs in transistors and optics. No
>> general purpose CPU to exploit.
>>>
>>>
>> https://www.scmagazine.com/news/thousands-of-devices-exposed-to-critical-cisco-ios-xe-software-bug
>>>
>>> Bob
>>>
>>> On Oct 18, 2023, 5:40 PM, at 5:40 PM, David Lang <david@lang.hm>
>> wrote:
>>>> On Sat, 14 Oct 2023, rjmcmahon wrote:
>>>>
>>>>> On being unleashed, I think this applies to consumer electronics
>> too.
>>>> Not
>>>>> sure why HDMI class cables will be needed. WiFi 7 is spec'd at 16
>>>> MIMO radios
>>>>> at 45Gb/s per front end module. Add some hw
>>>> compression/decompression, I
>>>>> think it can carry even HDMI Utlra High Speed or 8K. And the
>> content
>>>> will
>>>>> likely be coming from the cloud too, so the need for a short HDMI
>>>> cable kinda
>>>>> goes away.
>>>>
>>>> until you have a few people in an area all trying to do the same
>> thing,
>>>> not they
>>>> EACH need that much low-latency bandwith, and it just doesn't work
>>>> well.
>>>>
>>>>> Maybe I'm unique of being tired of having rats' nests of cables to
>>>> connect
>>>>> things. My thoughts are no more cables other than structured fiber
>>>> and
>>>>> structured AC which both are long lived, multiple decades or more,
>>>> and hence
>>>>> are a one and done type of spend.
>>>>
>>>> It's much more practical to go to a single USB-C cable (power,
>> video,
>>>> etc) than
>>>> it is to go completely wireless when you are stationary.
>>>>
>>>>> I'm not a fan of PLC, mixing power and comm. I've installed AFCI
>>>> circuit
>>>>> breakers for all my family, including the in laws. These can
>> trigger
>>>> easily
>>>>> when other signals are multiplexed.
>>>>>
>>>>> There were so many things that went wrong in The Bronx where 11
>>>> people died
>>>>> including children. An AFCI breaker would likely have prevented
>> that
>>>> fire.
>>>>> Working auto door closers would have helped. Providing heat pumps
>>>> would have
>>>>> helped too so kids didn't have to use electric resistive space
>>>> heaters which
>>>>> are terrible by my judgment.
>>>>>
>>>>> It's hard to believe that Notre Dame burned down too. We've got so
>>>>> improvement to do on life support systems.
>>>>
>>>> what's the retrofit cost vs the incrimental cost? (ROI timeframe),
>>>> that's
>>>> usually overlooked in these 'this technology is clearly better,
>>>> everyone should
>>>> be forced to switch to it' discussions.
>>>>
>>>> (and don't get me started on Rent Control, common in NYC, which
>>>> discourages
>>>> investments by landlords)
>>>>
>>>> David Lang
>>>>
>>>>> https://en.wikipedia.org/wiki/2022_Bronx_apartment_fire
>>>>>
>>>>> Bob
>>>>>> Hi Bob,
>>>>>>
>>>>>>
>>>>>>> On Oct 13, 2023, at 19:20, rjmcmahon <rjmcmahon@rjmcmahon.com>
>>>> wrote:
>>>>>>>
>>>>>>> Hi Sebastian,
>>>>>>>
>>>>>>> It was the ISP tech support over the phone. Trying to help
>> install
>>>> a home
>>>>>>> network over the phone w/o a technician isn't easy.
>>>>>>
>>>>>> 	[SM] Ah, okay. I would never even think about calling my ISP when
>>>>>> considering changes to my home network (for one, I would rather
>>>>>> McGywer this, and also my ISP does not really offer that as a
>>>>>> servicedsdw), I guess different service offerings in different
>>>>>> countries.
>>>>>>
>>>>>>
>>>>>>> In many U.S. states, smoke detectors are required to be no more
>>>> that 30'
>>>>>>> apart, must be AC powered, battery backed up and must communicate
>>>> with one
>>>>>>> another. The smoke sensor needs to be replaced every ten years
>> max.
>>>>>>
>>>>>> 	[SM] Intersting! Over here detectors are also mandatory (but no
>>>>>> distance or networking requirements, it is special rooms like bed
>>>>>> rooms that need to have one). Also over here no AC requirement.
>>>>>>
>>>>>>
>>>>>>> It's a good place to install remote radio heads, or even full
>> blown
>>>> APs,
>>>>>>> for both internet access points and for life support sensors.
>>>>>>
>>>>>> 	[SM] I agree, and with an AC requirement powering such APs/radio
>>>>>> heads is not rocket science either, heck in a first iteration one
>>>>>> might even use PLC to bring data to the APs...
>>>>>>
>>>>>>
>>>>>>> 10G NRE spends stopped over a decade ago. Early adopters aren't
>>>> likely
>>>>>>> going to wire 10G over copper in their homes.
>>>>>>
>>>>>> 	[SM] Over here active 2.5 Gbps ethernet are just becoming cheap
>>>>>> enough for enthusiasts to switch over to, and 2.5 has the
>> advantage
>>>> of
>>>>>> operating well even over most cat5 wiring (few homes I know will
>>>> push
>>>>>> anywhere close to the typical 100m copper ethernet limit, most
>> will
>>>> be
>>>>>> fine with < 30m).
>>>>>>
>>>>>>
>>>>>>> 100G only goes 4 meters so copper really isn't an option for
>> future
>>>> proof
>>>>>>> comm cable throughout buildings.
>>>>>>
>>>>>> 	[SM] Indeed, but I am not 100% sure what use-case would justify
>>>> going
>>>>>> 100Gbps in a typical home? Sure if one switches to fiber wiring
>> and
>>>>>> 100Gbps is only marginally more expensive than 1 or 10 Gbps why
>> not?
>>>>>>
>>>>>>> Fiber to WiFi seems straight forward to me.
>>>>>>
>>>>>> 	[SM] This might be related to your professional background
>> though?
>>>> ;)
>>>>>> Just kidding, I think you are simply a few years ahead of the rest
>>>> of
>>>>>> us, as you know what is in the pipeline.
>>>>>>
>>>>>>
>>>>>>> People don't want to be leashed to plugs so the last meters have
>> to
>>>> be
>>>>>>> wireless.
>>>>>>
>>>>>> 	[SM] Yes and no. People did not bother about wiring office desks
>> or
>>>>>> even smart TVs, but smart phones and tablets are a different
>> kettle
>>>> of
>>>>>> fish, as are laptops, that might be operated wired on the desk but
>>>>>> wireless in the rest of the house. I also note that more and more
>>>>>> laptops come without built in ethernet (personally I detest that,
>> an
>>>>>> rj45 jack is not that thick that a laptop body can not be planned
>>>>>> around that, leaving some more room for e.g. NVMe sockets or
>>>> simplify
>>>>>> cooling a bit, ultra-thin is IMHO not really in the end-users'
>>>>>> interest, but I digress).
>>>>>>
>>>>>>
>>>>>>> We need to standardized to the extent that we can on one wireless
>>>> tech
>>>>>>> (similar to Ethernet for wired) and a proposal is to use 802.11
>>>> since
>>>>>>> that's selling in volume, driven by mobile hand sets.
>>>>>>
>>>>>> 	[SM] Sure 802.11 is likely to stay by virtue of being relatively
>>>>>> ubiquitous and by being generally already good enough for many use
>>>>>> cases (with road-maps for tackling more demanding use-cases, and I
>>>>>> very much include your fiwi proposal here).
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Bob
>>>>>>>> Hi Bob,
>>>>>>>>> On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain
>>>>>>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>>>>>> Hi David,
>>>>>>>>> The vendors I know don't roll their own os code either. The
>> make
>>>> their
>>>>>>>>> own release still mostly based from Linux and they aren't tied
>> to
>>>> the
>>>>>>>>> openwrt release process.
>>>>>>>>> I think GUIs on CPEs are the wrong direction. Consumer network
>>>> equipment
>>>>>>>>> does best when it's plug and play. Consumers don't have all the
>>>> skills
>>>>>>>>> needed to manage an in home packet network that includes wifi.
>>>>>>>> 	[SM] That is both true, and (currently?) unachievable. To run a
>>>>>>>> network connected to the internet securely requires to make a
>>>> number
>>>>>>>> of policy decisions trading-off the required/desired
>> connectivity
>>>>>>>> versus the cost in security (either cost as effort of
>> maintaining
>>>>>>>> security or cost in an increase in attack surface).
>>>>>>>> 	The in-side the home situation, has IMHO drastically improved
>>>> with
>>>>>>>> the availability of off-the-shelf mesh network gear from
>>>> commercial
>>>>>>>> vendors, with easy to follow instructions and/or apps to find
>>>> decent
>>>>>>>> AP placement.
>>>>>>>> 	For structured wiring, I would agree that requires both an
>>>> unusual
>>>>>>>> skill set (even though doing structured wiring itself is not
>> hard,
>>>>>>>> just doing it in a way that blends into an apartment without
>>>> signaling
>>>>>>>> DIY-ness is more involved).
>>>>>>>>> I recently fixed a home network for my inlaws. It's a combo of
>>>>>>>>> structured wire and WiFi APs. I purchased the latest equipment
>>>> from
>>>>>>>>> Amazon vs use the ISP provided equipment. I can do this
>>>> reasonably well
>>>>>>>>> because I'm familiar with the chips inside.
>>>>>>>>> The online tech support started with trepidation as he was
>>>> concerned
>>>>>>>>> that the home owner, i.e me, wasn't as skilled as the ISP
>>>> technicians.
>>>>>>>>> He suggested we schedule that but I said we were good to go w/o
>>>> one.
>>>>>>>> 	[SM] What "online tech support"? From the AP vendor or from the
>>>> ISP?
>>>>>>>> The latter might have a script recommending ISP technicians more
>>>> for
>>>>>>>> commercial considerations than technical ones...
>>>>>>>>> He asked to speak to my father in law when we were all done. He
>>>> told
>>>>>>>>> him, "You're lucky to have a son in law that know what he's
>>>> doing. My
>>>>>>>>> techs aren't as good, and I really liked working with him too."
>>>>>>>>> I say this not to brag, as many on this list could do the
>>>> equivalent,
>>>>>>>>> but to show that we really need to train lots of technicians on
>>>> things
>>>>>>>>> like RF and structured wiring. Nobody should be "lucky" to get
>> a
>>>> quality
>>>>>>>>> in home network.  We're not lucky to have a flush toilet
>> anymore.
>>>> This
>>>>>>>>> stuff is too important to rely on luck.
>>>>>>>> 	[SM] Mmmh, that got me thinking, maybe we should think about
>>>> always
>>>>>>>> running network wiring parallel to electric cables so each power
>>>>>>>> socket could easily house an ethernet plug as well... (or one
>> per
>>>> room
>>>>>>>> to keep the cost lower and avoid overly much "dark" copper)?
>> Sort
>>>> of
>>>>>>>> put this into the building codes/best current practice
>>>> documents... (I
>>>>>>>> understand starting now, will still only solve the issue over
>> many
>>>>>>>> decades, but at least we would be making some inroads; and
>>>> speaking of
>>>>>>>> decades, maybe putting fiber there instead of copper might be a
>>>> more
>>>>>>>> future-oriented approach)?
>>>>>>>>> Bob
>>>>>>>>> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>>>>>>> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>>>>>>> I don't know the numbers but a guess is that a majority of SoCs
>>>> with
>>>>>>>>> WiFi
>>>>>>>>> radios aren't based on openwrt.
>>>>>>>>> From what I've seen, the majority of APs out there are based on
>>>> OpenWRT
>>>>>>>>> or one
>>>>>>>>> of the competing open projects, very few roll their own OS from
>>>> scratch
>>>>>>>>> I think many on this list use openwrt but
>>>>>>>>> that may not be representative of the actuals. Also, the trend
>> is
>>>> less
>>>>>>>>> sw in
>>>>>>>>> a CPU forwarding plane and more hw, one day, linux at the CPEs
>>>> may not
>>>>>>>>> be
>>>>>>>>> needed at all (if we get to remote radio heads - though this is
>>>> highly
>>>>>>>>> speculative.)
>>>>>>>>> that is countered by the trend to do more (fancier GUI, media
>>>> center,
>>>>>>>>> etc) The
>>>>>>>>> vendors all want to differentiate themselves, that's hard to do
>>>> if it's
>>>>>>>>> baked
>>>>>>>>> into the chips
>>>>>>>>> From my experience, sw is defined by the number & frequency of
>>>> commits,
>>>>>>>>> and
>>>>>>>>> of timeliness to issues more than a version number or compile
>>>> date. So
>>>>>>>>> the
>>>>>>>>> size and quality of the software staff can be informative.
>>>>>>>>> I'm more interested in mfg node process then the mfg location &
>>>> date as
>>>>>>>>> the
>>>>>>>>> node process gives an idea if the design is keeping up or not.
>>>> Chips
>>>>>>>>> designed
>>>>>>>>> in 2012 are woefully behind and consume too much energy and
>>>> generate too
>>>>>>>>> much
>>>>>>>>> heat. I think Intel provides this information on all its chips
>> as
>>>> an
>>>>>>>>> example.
>>>>>>>>> I'm far less concerned about the chips than the software.
>>>> Security holes
>>>>>>>>> are far
>>>>>>>>> more likely in the software than the chips. The chips may limit
>>>> the max
>>>>>>>>> performance of the devices, but the focus of this is on the
>>>> security,
>>>>>>>>> not the
>>>>>>>>> throughput or the power efficiency (I don't mind that extra
>> info,
>>>> but
>>>>>>>>> what makes
>>>>>>>>> some device unsafe to use isn't the age of the chips, but the
>> age
>>>> of the
>>>>>>>>> software)
>>>>>>>>> David Lang
>>>>>>>>> Bob
>>>>>>>>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>>>>>>> There's also the concern about how do startups roll-out such a
>>>> label for
>>>>>>>>> their tech in the early iteration phase? How do they afford to
>> do
>>>> the
>>>>>>>>> extra
>>>>>>>>> work for the label vs. a big company (does this become a
>>>> regulatory
>>>>>>>>> moat?)
>>>>>>>>> And let's say we have these labels. Will only consumers with
>> the
>>>> money
>>>>>>>>> to
>>>>>>>>> purchase the more expensive equipment that has more privacy and
>>>> security
>>>>>>>>> features buy that one - leaving those who cannot afford privacy
>>>> and
>>>>>>>>> security bad alternatives?
>>>>>>>>> As far as security goes, I would argue that the easy answer is
>> to
>>>> ship
>>>>>>>>> a current version of openwrt instead of a forked, ancient
>>>> version, and
>>>>>>>>> get their changes submitted upstream (or at least maintained
>>>> against
>>>>>>>>> upstream). It's a different paradigm than they are used to, and
>>>> right
>>>>>>>>> now the suppliers tend to also work with ancient versions of
>>>> openwrt,
>>>>>>>>> but in all the companies that I have worked at, it's proven to
>> be
>>>> less
>>>>>>>>> ongoing work (and far less risk) to keep up with current
>> versions
>>>> than
>>>>>>>>> it is to stick with old versions and then do periodic 'big
>> jump'
>>>>>>>>> upgrades.
>>>>>>>>> it's like car maintinance, it seems easier to ignore your
>> tires,
>>>>>>>>> brakes, and oil changes, but the minimal cost of maintaining
>>>> those
>>>>>>>>> systems pays off in a big way over time
>>>>>>>>> David Lang
>>>>>>>>> Nnagain mailing list
>>>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>>>>> Nnagain mailing list
>>>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>>>>> _______________________________________________
>>>>>>>>> Nnagain mailing list
>>>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>
>>>
>

Re: [NNagain] Internet Education for Non-technorati?

[rjmcmahon]

Well, way off topic, heat pumps are a step in a better direction than 
expensive space heaters, particularly for kids in public housing.

Fiber wave-guides are low energy, too compared to all other wave guides 
and better than free space as function of distance.

I don't think there is a physicist on the planet that would dispute 
either statement, or who could design an experiment proving otherwise. 
I'm doubtful there is any research monies being spent on increasing the 
net energy return by burning fuels and releasing C02 to run electric 
resistive space heaters. Evan Tesla's have heat pumps. Their cars would 
go to near zero range in the NE winters if they used electric resistive 
to heat the passenger cabins.

 From https://heet.org/

3.1 Air-Source Heat Pumps
An air-source heat pump (ASHP) provides space
heating and cooling using outdoor air as a thermal
source. Typically, an ASHP is relatively inexpensive
to operate compared to traditional heating and
cooling equipment. This is because less energy is
required to move heat than it is to convert it from
a fuel source (e.g., the combustion of natural gas for
heating).

As mentioned earlier in this Chapter, ASHP
performance decreases as the difference between
ambient outdoor and indoor air temperatures
increase. In very cold climates there is also a risk of
frost forming on the outdoor components of the
ASHP system, which further increases the difference
between temperatures and decreases heating
efficiency.

5 U.S. Department of Energy, Air-Source Heat Pumps. 
https://www.energy.gov/energysaver/heat-pump-systems/air-source-heat-pumps
Because of these issues, the use of ASHP systems
was once limited to warmer and more moderate
climates. However, improvements in heat pump
technology have made them a legitimate alternative
to fossil fuel space heating in colder regions such as
New England.5

Bob
> assuming a single floor house with lose insulation in the attic
> 
> now look at a multi-story place where there isn't an attic, or one
> with trusses so that moving around the attic is hard, or a SIP
> cealing, cathedral cealings, etc.
> 
> but my initial comment on ROI and refitting cost was actually directed
> at the proposal to make heat pump retrofits mandatory.
> 
> David Lang
> 
> On Wed, 18 Oct 2023, Robert McMahon wrote:
> 
>> Retrofit is trivial. It's all in the attic. A romex splice is about 
>> $53. Verticals aren't required.
>> 
>> Many states are mandating per each sale. I had to do this in Boston 
>> historic district. No grandfather. My fire hurts the entire street
>> 
>> ⁣Bob
>> 
>> On Oct 18, 2023, 7:05 PM, at 7:05 PM, David Lang <david@lang.hm> 
>> wrote:
>>> On Wed, 18 Oct 2023, Robert McMahon wrote:
>>> 
>>>> It's $428 per ac ceiling mount hardwired device, no verticals. It's
>>> $503 per vertical for rg6 with patch n paint, internal walls only.
>>>> 
>>>> The asset value add for a rg6 jack is basically zero. The asset 
>>>> value
>>> add for whole home, life support capable, future proof,  low power,
>>> structured fiber & remote radio head is $2,857.
>>>> 
>>>> Staying ceiling mount helps a lot, no need for holes in the walls 
>>>> and
>>> no patch and paint.
>>>> 
>>>> All homes sold in the U.S. will have to do this per 2027 fire codes.
>>> The smart ones will connect the fiber fronthaul to capture the 
>>> $2,857.
>>> Home networking is second behind in unit laundry for landlords. Rent
>>> increase for 100Gb/s point to point full duplex FiWi won't be known
>>> until after the $100M NRE spend to create the radio sticks.
>>> 
>>> No, all NEW homes built will need it, old homes do not need to be
>>> retrofitted.
>>> This is normal for many things.
>>> 
>>> It's cheap to do this sort of thing when a house is built, it's FAR
>>> more
>>> expensive to retrofit a house.
>>> 
>>> David Lang
>>> 
>>>> No security vulnerabilities compared to those found in Linux
>>> computers. The radio stick is DSPs in transistors and optics. No
>>> general purpose CPU to exploit.
>>>> 
>>>> 
>>> https://www.scmagazine.com/news/thousands-of-devices-exposed-to-critical-cisco-ios-xe-software-bug
>>>> 
>>>> Bob
>>>> 
>>>> On Oct 18, 2023, 5:40 PM, at 5:40 PM, David Lang <david@lang.hm>
>>> wrote:
>>>>> On Sat, 14 Oct 2023, rjmcmahon wrote:
>>>>> 
>>>>>> On being unleashed, I think this applies to consumer electronics
>>> too.
>>>>> Not
>>>>>> sure why HDMI class cables will be needed. WiFi 7 is spec'd at 16
>>>>> MIMO radios
>>>>>> at 45Gb/s per front end module. Add some hw
>>>>> compression/decompression, I
>>>>>> think it can carry even HDMI Utlra High Speed or 8K. And the
>>> content
>>>>> will
>>>>>> likely be coming from the cloud too, so the need for a short HDMI
>>>>> cable kinda
>>>>>> goes away.
>>>>> 
>>>>> until you have a few people in an area all trying to do the same
>>> thing,
>>>>> not they
>>>>> EACH need that much low-latency bandwith, and it just doesn't work
>>>>> well.
>>>>> 
>>>>>> Maybe I'm unique of being tired of having rats' nests of cables to
>>>>> connect
>>>>>> things. My thoughts are no more cables other than structured fiber
>>>>> and
>>>>>> structured AC which both are long lived, multiple decades or more,
>>>>> and hence
>>>>>> are a one and done type of spend.
>>>>> 
>>>>> It's much more practical to go to a single USB-C cable (power,
>>> video,
>>>>> etc) than
>>>>> it is to go completely wireless when you are stationary.
>>>>> 
>>>>>> I'm not a fan of PLC, mixing power and comm. I've installed AFCI
>>>>> circuit
>>>>>> breakers for all my family, including the in laws. These can
>>> trigger
>>>>> easily
>>>>>> when other signals are multiplexed.
>>>>>> 
>>>>>> There were so many things that went wrong in The Bronx where 11
>>>>> people died
>>>>>> including children. An AFCI breaker would likely have prevented
>>> that
>>>>> fire.
>>>>>> Working auto door closers would have helped. Providing heat pumps
>>>>> would have
>>>>>> helped too so kids didn't have to use electric resistive space
>>>>> heaters which
>>>>>> are terrible by my judgment.
>>>>>> 
>>>>>> It's hard to believe that Notre Dame burned down too. We've got so
>>>>>> improvement to do on life support systems.
>>>>> 
>>>>> what's the retrofit cost vs the incrimental cost? (ROI timeframe),
>>>>> that's
>>>>> usually overlooked in these 'this technology is clearly better,
>>>>> everyone should
>>>>> be forced to switch to it' discussions.
>>>>> 
>>>>> (and don't get me started on Rent Control, common in NYC, which
>>>>> discourages
>>>>> investments by landlords)
>>>>> 
>>>>> David Lang
>>>>> 
>>>>>> https://en.wikipedia.org/wiki/2022_Bronx_apartment_fire
>>>>>> 
>>>>>> Bob
>>>>>>> Hi Bob,
>>>>>>> 
>>>>>>> 
>>>>>>>> On Oct 13, 2023, at 19:20, rjmcmahon <rjmcmahon@rjmcmahon.com>
>>>>> wrote:
>>>>>>>> 
>>>>>>>> Hi Sebastian,
>>>>>>>> 
>>>>>>>> It was the ISP tech support over the phone. Trying to help
>>> install
>>>>> a home
>>>>>>>> network over the phone w/o a technician isn't easy.
>>>>>>> 
>>>>>>> 	[SM] Ah, okay. I would never even think about calling my ISP 
>>>>>>> when
>>>>>>> considering changes to my home network (for one, I would rather
>>>>>>> McGywer this, and also my ISP does not really offer that as a
>>>>>>> servicedsdw), I guess different service offerings in different
>>>>>>> countries.
>>>>>>> 
>>>>>>> 
>>>>>>>> In many U.S. states, smoke detectors are required to be no more
>>>>> that 30'
>>>>>>>> apart, must be AC powered, battery backed up and must 
>>>>>>>> communicate
>>>>> with one
>>>>>>>> another. The smoke sensor needs to be replaced every ten years
>>> max.
>>>>>>> 
>>>>>>> 	[SM] Intersting! Over here detectors are also mandatory (but no
>>>>>>> distance or networking requirements, it is special rooms like bed
>>>>>>> rooms that need to have one). Also over here no AC requirement.
>>>>>>> 
>>>>>>> 
>>>>>>>> It's a good place to install remote radio heads, or even full
>>> blown
>>>>> APs,
>>>>>>>> for both internet access points and for life support sensors.
>>>>>>> 
>>>>>>> 	[SM] I agree, and with an AC requirement powering such APs/radio
>>>>>>> heads is not rocket science either, heck in a first iteration one
>>>>>>> might even use PLC to bring data to the APs...
>>>>>>> 
>>>>>>> 
>>>>>>>> 10G NRE spends stopped over a decade ago. Early adopters aren't
>>>>> likely
>>>>>>>> going to wire 10G over copper in their homes.
>>>>>>> 
>>>>>>> 	[SM] Over here active 2.5 Gbps ethernet are just becoming cheap
>>>>>>> enough for enthusiasts to switch over to, and 2.5 has the
>>> advantage
>>>>> of
>>>>>>> operating well even over most cat5 wiring (few homes I know will
>>>>> push
>>>>>>> anywhere close to the typical 100m copper ethernet limit, most
>>> will
>>>>> be
>>>>>>> fine with < 30m).
>>>>>>> 
>>>>>>> 
>>>>>>>> 100G only goes 4 meters so copper really isn't an option for
>>> future
>>>>> proof
>>>>>>>> comm cable throughout buildings.
>>>>>>> 
>>>>>>> 	[SM] Indeed, but I am not 100% sure what use-case would justify
>>>>> going
>>>>>>> 100Gbps in a typical home? Sure if one switches to fiber wiring
>>> and
>>>>>>> 100Gbps is only marginally more expensive than 1 or 10 Gbps why
>>> not?
>>>>>>> 
>>>>>>>> Fiber to WiFi seems straight forward to me.
>>>>>>> 
>>>>>>> 	[SM] This might be related to your professional background
>>> though?
>>>>> ;)
>>>>>>> Just kidding, I think you are simply a few years ahead of the 
>>>>>>> rest
>>>>> of
>>>>>>> us, as you know what is in the pipeline.
>>>>>>> 
>>>>>>> 
>>>>>>>> People don't want to be leashed to plugs so the last meters have
>>> to
>>>>> be
>>>>>>>> wireless.
>>>>>>> 
>>>>>>> 	[SM] Yes and no. People did not bother about wiring office desks
>>> or
>>>>>>> even smart TVs, but smart phones and tablets are a different
>>> kettle
>>>>> of
>>>>>>> fish, as are laptops, that might be operated wired on the desk 
>>>>>>> but
>>>>>>> wireless in the rest of the house. I also note that more and more
>>>>>>> laptops come without built in ethernet (personally I detest that,
>>> an
>>>>>>> rj45 jack is not that thick that a laptop body can not be planned
>>>>>>> around that, leaving some more room for e.g. NVMe sockets or
>>>>> simplify
>>>>>>> cooling a bit, ultra-thin is IMHO not really in the end-users'
>>>>>>> interest, but I digress).
>>>>>>> 
>>>>>>> 
>>>>>>>> We need to standardized to the extent that we can on one 
>>>>>>>> wireless
>>>>> tech
>>>>>>>> (similar to Ethernet for wired) and a proposal is to use 802.11
>>>>> since
>>>>>>>> that's selling in volume, driven by mobile hand sets.
>>>>>>> 
>>>>>>> 	[SM] Sure 802.11 is likely to stay by virtue of being relatively
>>>>>>> ubiquitous and by being generally already good enough for many 
>>>>>>> use
>>>>>>> cases (with road-maps for tackling more demanding use-cases, and 
>>>>>>> I
>>>>>>> very much include your fiwi proposal here).
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Bob
>>>>>>>>> Hi Bob,
>>>>>>>>>> On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain
>>>>>>>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>> The vendors I know don't roll their own os code either. The
>>> make
>>>>> their
>>>>>>>>>> own release still mostly based from Linux and they aren't tied
>>> to
>>>>> the
>>>>>>>>>> openwrt release process.
>>>>>>>>>> I think GUIs on CPEs are the wrong direction. Consumer network
>>>>> equipment
>>>>>>>>>> does best when it's plug and play. Consumers don't have all 
>>>>>>>>>> the
>>>>> skills
>>>>>>>>>> needed to manage an in home packet network that includes wifi.
>>>>>>>>> 	[SM] That is both true, and (currently?) unachievable. To run 
>>>>>>>>> a
>>>>>>>>> network connected to the internet securely requires to make a
>>>>> number
>>>>>>>>> of policy decisions trading-off the required/desired
>>> connectivity
>>>>>>>>> versus the cost in security (either cost as effort of
>>> maintaining
>>>>>>>>> security or cost in an increase in attack surface).
>>>>>>>>> 	The in-side the home situation, has IMHO drastically improved
>>>>> with
>>>>>>>>> the availability of off-the-shelf mesh network gear from
>>>>> commercial
>>>>>>>>> vendors, with easy to follow instructions and/or apps to find
>>>>> decent
>>>>>>>>> AP placement.
>>>>>>>>> 	For structured wiring, I would agree that requires both an
>>>>> unusual
>>>>>>>>> skill set (even though doing structured wiring itself is not
>>> hard,
>>>>>>>>> just doing it in a way that blends into an apartment without
>>>>> signaling
>>>>>>>>> DIY-ness is more involved).
>>>>>>>>>> I recently fixed a home network for my inlaws. It's a combo of
>>>>>>>>>> structured wire and WiFi APs. I purchased the latest equipment
>>>>> from
>>>>>>>>>> Amazon vs use the ISP provided equipment. I can do this
>>>>> reasonably well
>>>>>>>>>> because I'm familiar with the chips inside.
>>>>>>>>>> The online tech support started with trepidation as he was
>>>>> concerned
>>>>>>>>>> that the home owner, i.e me, wasn't as skilled as the ISP
>>>>> technicians.
>>>>>>>>>> He suggested we schedule that but I said we were good to go 
>>>>>>>>>> w/o
>>>>> one.
>>>>>>>>> 	[SM] What "online tech support"? From the AP vendor or from 
>>>>>>>>> the
>>>>> ISP?
>>>>>>>>> The latter might have a script recommending ISP technicians 
>>>>>>>>> more
>>>>> for
>>>>>>>>> commercial considerations than technical ones...
>>>>>>>>>> He asked to speak to my father in law when we were all done. 
>>>>>>>>>> He
>>>>> told
>>>>>>>>>> him, "You're lucky to have a son in law that know what he's
>>>>> doing. My
>>>>>>>>>> techs aren't as good, and I really liked working with him 
>>>>>>>>>> too."
>>>>>>>>>> I say this not to brag, as many on this list could do the
>>>>> equivalent,
>>>>>>>>>> but to show that we really need to train lots of technicians 
>>>>>>>>>> on
>>>>> things
>>>>>>>>>> like RF and structured wiring. Nobody should be "lucky" to get
>>> a
>>>>> quality
>>>>>>>>>> in home network.  We're not lucky to have a flush toilet
>>> anymore.
>>>>> This
>>>>>>>>>> stuff is too important to rely on luck.
>>>>>>>>> 	[SM] Mmmh, that got me thinking, maybe we should think about
>>>>> always
>>>>>>>>> running network wiring parallel to electric cables so each 
>>>>>>>>> power
>>>>>>>>> socket could easily house an ethernet plug as well... (or one
>>> per
>>>>> room
>>>>>>>>> to keep the cost lower and avoid overly much "dark" copper)?
>>> Sort
>>>>> of
>>>>>>>>> put this into the building codes/best current practice
>>>>> documents... (I
>>>>>>>>> understand starting now, will still only solve the issue over
>>> many
>>>>>>>>> decades, but at least we would be making some inroads; and
>>>>> speaking of
>>>>>>>>> decades, maybe putting fiber there instead of copper might be a
>>>>> more
>>>>>>>>> future-oriented approach)?
>>>>>>>>>> Bob
>>>>>>>>>> On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
>>>>>>>>>> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>>>>>>>> I don't know the numbers but a guess is that a majority of 
>>>>>>>>>> SoCs
>>>>> with
>>>>>>>>>> WiFi
>>>>>>>>>> radios aren't based on openwrt.
>>>>>>>>>> From what I've seen, the majority of APs out there are based 
>>>>>>>>>> on
>>>>> OpenWRT
>>>>>>>>>> or one
>>>>>>>>>> of the competing open projects, very few roll their own OS 
>>>>>>>>>> from
>>>>> scratch
>>>>>>>>>> I think many on this list use openwrt but
>>>>>>>>>> that may not be representative of the actuals. Also, the trend
>>> is
>>>>> less
>>>>>>>>>> sw in
>>>>>>>>>> a CPU forwarding plane and more hw, one day, linux at the CPEs
>>>>> may not
>>>>>>>>>> be
>>>>>>>>>> needed at all (if we get to remote radio heads - though this 
>>>>>>>>>> is
>>>>> highly
>>>>>>>>>> speculative.)
>>>>>>>>>> that is countered by the trend to do more (fancier GUI, media
>>>>> center,
>>>>>>>>>> etc) The
>>>>>>>>>> vendors all want to differentiate themselves, that's hard to 
>>>>>>>>>> do
>>>>> if it's
>>>>>>>>>> baked
>>>>>>>>>> into the chips
>>>>>>>>>> From my experience, sw is defined by the number & frequency of
>>>>> commits,
>>>>>>>>>> and
>>>>>>>>>> of timeliness to issues more than a version number or compile
>>>>> date. So
>>>>>>>>>> the
>>>>>>>>>> size and quality of the software staff can be informative.
>>>>>>>>>> I'm more interested in mfg node process then the mfg location 
>>>>>>>>>> &
>>>>> date as
>>>>>>>>>> the
>>>>>>>>>> node process gives an idea if the design is keeping up or not.
>>>>> Chips
>>>>>>>>>> designed
>>>>>>>>>> in 2012 are woefully behind and consume too much energy and
>>>>> generate too
>>>>>>>>>> much
>>>>>>>>>> heat. I think Intel provides this information on all its chips
>>> as
>>>>> an
>>>>>>>>>> example.
>>>>>>>>>> I'm far less concerned about the chips than the software.
>>>>> Security holes
>>>>>>>>>> are far
>>>>>>>>>> more likely in the software than the chips. The chips may 
>>>>>>>>>> limit
>>>>> the max
>>>>>>>>>> performance of the devices, but the focus of this is on the
>>>>> security,
>>>>>>>>>> not the
>>>>>>>>>> throughput or the power efficiency (I don't mind that extra
>>> info,
>>>>> but
>>>>>>>>>> what makes
>>>>>>>>>> some device unsafe to use isn't the age of the chips, but the
>>> age
>>>>> of the
>>>>>>>>>> software)
>>>>>>>>>> David Lang
>>>>>>>>>> Bob
>>>>>>>>>> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>>>>>>>> There's also the concern about how do startups roll-out such a
>>>>> label for
>>>>>>>>>> their tech in the early iteration phase? How do they afford to
>>> do
>>>>> the
>>>>>>>>>> extra
>>>>>>>>>> work for the label vs. a big company (does this become a
>>>>> regulatory
>>>>>>>>>> moat?)
>>>>>>>>>> And let's say we have these labels. Will only consumers with
>>> the
>>>>> money
>>>>>>>>>> to
>>>>>>>>>> purchase the more expensive equipment that has more privacy 
>>>>>>>>>> and
>>>>> security
>>>>>>>>>> features buy that one - leaving those who cannot afford 
>>>>>>>>>> privacy
>>>>> and
>>>>>>>>>> security bad alternatives?
>>>>>>>>>> As far as security goes, I would argue that the easy answer is
>>> to
>>>>> ship
>>>>>>>>>> a current version of openwrt instead of a forked, ancient
>>>>> version, and
>>>>>>>>>> get their changes submitted upstream (or at least maintained
>>>>> against
>>>>>>>>>> upstream). It's a different paradigm than they are used to, 
>>>>>>>>>> and
>>>>> right
>>>>>>>>>> now the suppliers tend to also work with ancient versions of
>>>>> openwrt,
>>>>>>>>>> but in all the companies that I have worked at, it's proven to
>>> be
>>>>> less
>>>>>>>>>> ongoing work (and far less risk) to keep up with current
>>> versions
>>>>> than
>>>>>>>>>> it is to stick with old versions and then do periodic 'big
>>> jump'
>>>>>>>>>> upgrades.
>>>>>>>>>> it's like car maintinance, it seems easier to ignore your
>>> tires,
>>>>>>>>>> brakes, and oil changes, but the minimal cost of maintaining
>>>>> those
>>>>>>>>>> systems pays off in a big way over time
>>>>>>>>>> David Lang
>>>>>>>>>> Nnagain mailing list
>>>>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>>>>>> Nnagain mailing list
>>>>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Nnagain mailing list
>>>>>>>>>> Nnagain@lists.bufferbloat.net
>>>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> 
>>>> 
>> 

Re: [NNagain] Internet Education for Non-technorati?

[Sebastian Moeller]

Hi Jack,


> On Oct 11, 2023, at 19:31, Jack Haverty via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> 
> A few days ago I made some comments about the idea of "educating" the lawyers, politicians, and other smart, but not necessarily technically adept, decision makers.  Today I saw a news story about a recent FCC action, to mandate "nutrition labels" on Internet services offered by ISPs:
> 
> https://cordcuttersnews.com/fcc-says-comcast-spectrum-att-must-start-displaying-the-true-cost-and-speed-of-their-internet-service-starting-april-2024/
> 
> This struck me as anecdotal, but a good example of the need for education.  Although it's tempting and natural to look at existing infrastructures as models for regulating a new one, IMHO the Internet does not work like the Food/Agriculture infrastructure does.
> 
> For example, the new mandates require ISPs to "label" their products with "nutritional" data including "typical" latency, upload, and download speeds.   They have until April 2024 to figure it out. I've never encountered an ISP who could answer such questions - even the ones I was involved in managing.  Marketing can of course create an answer, since "typical" is such a vague term.  Figuring out how to attach the physical label to their service product may be a problem.

	[SM] There are typically several ways to skin this specific cat ;) One is e.g. for the regulator to supply their own reference platform against which the contractually agree upon rates/latency/random loss numbers are measured. In the EU the BEREC summarizes its recommendations e.g. here:
https://www.berec.europa.eu/sites/default/files/files/document_register_store/2022/6/BoR_%2822%29_72_NN_regulatory_assessment_methodology_final.pdf
where it is especially recommended to measure against servers outside of the ISP' networks... which makes a ton of sense for a product called internet access service, and not ISP-intranet access service ;)
Reading this document makes it clear that perfect is the enemy of the good and/or achievable in this matter.


> Such labels may not be very helpful to the end user struggling to find an ISP that delivers the service needed for some interactive use (audio or video conferencing, gaming, home automation, etc.)

	[SM] Sure. Now if the applicable law is amended to:
a) allow the ISP to freely specify the rate numbers they promise to customers (in the different plans)
b) actually hold them accountable to deliver on these promised rates

the whole thing starts to make some sense... (In Germany, the only regulatory area where I looked close enough, the law gives end users the right to immediate cancelation or to reduce the payment to be in proportion to the ratio of achieved rate versus contracted rate). And all of the ISP essentially follow the law, none went bankrupt because of this or lost all of their customers as far as I know... The point is such a scheme, while conceptually a bit unclean, can actually work pretty well in practice.


> Performance on the Internet depends on where the two endpoints are, the physical path to get from one to the other, as well as the hardware, software, current load, and other aspects of each endpoint, all outside the ISPs' control or vision.   Since the two endpoints can be on different ISPs, perhaps requiring one or more additional internediate ISPs, specifying a "typical" performance from all Points A to all Points B is even more challenging.

	[SM] Sure, and since the product is internet access, ideally the test servers would be located all over the network in diverse ASs, but short of such an unobtainable perfect system it seems an acceptable fudge to simply create a reference server system that is not hosted by any eye-ball ISP and is well connected to all major transit suppliers and/or important local IXs.


> Switching to the transportation analogy, one might ask your local bus or rail company what their typical time is to get from one city to another.   If the two cities involved happen to be on their rail or bus network, perhaps you can get an answer, but it will still depend on where the two endpoints are.  If one or both cities are not on their rail network, the travel time might have to include use of other "networks" - bus, rental car, airplane, ship, etc.   How long does it typically take for you to get from any city on the planet to any other city on the planet?

	[SM] We already hold transport companies accountable for extreme delays... (ever got abandoned on an airport somewhere between your start and end point for an additional over-night stay?)


> IMHO, rules and regulations for the Internet need to reflect how the Internet actually works.  That's why I suggested a focus on education for the decision makers.

	[SM] Sure education does work. however for the problem at hand it might make sense to look at already deployed "solutions" to similar problems...

Regards
	Sebastian


P.S.: I am not arguing the EU regulation is perfect in any way (and also not completely free of lobby influence), but IMHO it clearly is better than nothing, and might already be good enough.

> 
> Jack Haverty
> 
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Internet Education for Non-technorati?

[Hal Murray]

Jack Haverty said:
> A few days ago I made some comments about the idea of "educating" the
> lawyers, politicians, and other smart, but not necessarily technically
> adept, decision makers.

That process might work.

Stanford has run programs on cyber security for congressional staffers.

From 2015:
Congressional Staffers Headed to Stanford for Cybersecurity Training
https://cisac.fsi.stanford.edu/news/congressional-staffers-headed-stanford-cybe
rsecurity-training



> Today I saw a news story about a recent FCC action, to mandate "nutrition
> labels" on Internet services offered by ISPs:

Is there a chicken-egg problem in this area?

Suppose I had a nutrition-label sort of spec for a retail ISP offering.  How 
would I know if an installation was meeting the specs?  That seems to need a 
way to collect data -- either stand alone programs or patches to existing 
programs like web browsers.

Would it make sense to work on those programs now?  How much could we learn if 
volunteers ran those programs and contributed data to a public data base?  How 
many volunteers would we need to get off the ground?


Could servers collect useful data?  Consider Zoom, YouTube, gmail, downloads 
for software updates...



-- 
These are my opinions.  I hate spam.

Re: [NNagain] Internet Education for Non-technorati?

[Jack Haverty]

[-- Attachment #1: Type: text/plain, Size: 4276 bytes --]

Good point -- "How would I know if an installation was meeting the specs?"

It *has* been done before.  From a historical perspective...

When TCPV4 was being defined and documented in RFCs (e.g., RFC 793), 
circa 1981, other activities were happening in the administrative 
bureaucracy of the US government, outside the realm of the "research 
community".

The US Department of Defense, which purchases huge quantities of 
electronic equipment, declared TCP to be a "DoD Standard" in the early 
1980s.  Further, they changed their purchasing rules so that all 
equipment purchased, which might need to communicate to other equipment, 
had to implement TCP.  If you wanted to sell your networked products to 
the government, they had to implement TCP. This caused industry to 
suddenly pay attention to what us crazy researchers had done in creating 
this TCP thing.

A separate piece of government, the US National Bureau of Standards (now 
called NIST), defined a testing procedure for verifying that a 
particular TCP implementation actually conformed to the documented DoD 
Standard.   Further, they also created a program which would certify 
third-party labs as qualified to perform those tests and issue 
conformance certificates.   Such conformance proof could be submitted by 
companies as part of their sales process to supply equipment for DoD 
contracts.

I remember this pretty well, since I set up one such TCP Conformance 
Lab, got it certified, and we performed a lot of testing and consulting 
to help traditional government contractors figure out what TCP was all 
about and get their products certified for DoD procurement.  I've never 
learned who was orchestrating those bureaucratic initiatives, but it 
seemed like a good idea. There may have been other similar efforts in 
other countries over the decades since 1981 that I don't know anything 
about.

In the last 40+ years, AFAIK little else has happened for testing, 
certification, or regulation of Internet technology.   Hundreds, perhaps 
thousands, of "standards" have been created by IETF and others, defining 
new protocols, algorithms, and mechanisms for use in the Internet.  I'm 
not aware of any testing or certification for any Internet technology 
today, or any way to tell is f any product or service I might buy 
actually has implemented, correctly, any particular "Internet Standard".

Governments can create such mechanisms around important infrastructures, 
and have done so for transportation and many others.  IMHO they could do 
the same for Internet, and seem to be trying to do so.

But to be effective the administrators, politicians, and regulators need 
to know more about how the Internet works.   They could create 
"Conformance Labs".   They could involve organizations such as the 
Underwriters Lab in the US, CSA in Canada, CE (European Conformity) et al.

If they knew they could and decided they should .... Education...

Jack Haverty

On 10/12/23 12:52, Hal Murray via Nnagain wrote:
> Jack Haverty said:
>> A few days ago I made some comments about the idea of "educating" the
>> lawyers, politicians, and other smart, but not necessarily technically
>> adept, decision makers.
> That process might work.
>
> Stanford has run programs on cyber security for congressional staffers.
>
>  From 2015:
> Congressional Staffers Headed to Stanford for Cybersecurity Training
> https://cisac.fsi.stanford.edu/news/congressional-staffers-headed-stanford-cybe
> rsecurity-training
>
>
>
>> Today I saw a news story about a recent FCC action, to mandate "nutrition
>> labels" on Internet services offered by ISPs:
> Is there a chicken-egg problem in this area?
>
> Suppose I had a nutrition-label sort of spec for a retail ISP offering.  How
> would I know if an installation was meeting the specs?  That seems to need a
> way to collect data -- either stand alone programs or patches to existing
> programs like web browsers.
>
> Would it make sense to work on those programs now?  How much could we learn if
> volunteers ran those programs and contributed data to a public data base?  How
> many volunteers would we need to get off the ground?
>
>
> Could servers collect useful data?  Consider Zoom, YouTube, gmail, downloads
> for software updates...
>
>
>

[-- Attachment #2: Type: text/html, Size: 5531 bytes --]

Re: [NNagain] Internet Education for Non-technorati?

[rjmcmahon]

As an open-source maintainer of iperf 2, which is basically a network 
socket & traffic tool, I find this history extremely interesting. 
Releasing a measurement tool free to all, with transparent code, allows 
everyone access to a "shared yardstick." While maybe not enough, 
hopefully, it helps a little bit to those 40+ years of not much.

Bob
> Good point -- "How would I know if an installation was meeting the
> specs?"
> 
> It *has* been done before.  From a historical perspective...
> 
> When TCPV4 was being defined and documented in RFCs (e.g., RFC 793),
> circa 1981, other activities were happening in the administrative
> bureaucracy of the US government, outside the realm of the "research
> community".
> 
> The US Department of Defense, which purchases huge quantities of
> electronic equipment, declared TCP to be a "DoD Standard" in the early
> 1980s.  Further, they changed their purchasing rules so that all
> equipment purchased, which might need to communicate to other
> equipment, had to implement TCP.  If you wanted to sell your networked
> products to the government, they had to implement TCP.   This caused
> industry to suddenly pay attention to what us crazy researchers had
> done in creating this TCP thing.
> 
> A separate piece of government, the US National Bureau of Standards
> (now called NIST), defined a testing procedure for verifying that a
> particular TCP implementation actually conformed to the documented DoD
> Standard.   Further, they also created a program which would certify
> third-party labs as qualified to perform those tests and issue
> conformance certificates.   Such conformance proof could be submitted
> by companies as part of their sales process to supply equipment for
> DoD contracts.
> 
> I remember this pretty well, since I set up one such TCP Conformance
> Lab, got it certified, and we performed a lot of testing and
> consulting to help traditional government contractors figure out what
> TCP was all about and get their products certified for DoD
> procurement.  I've never learned who was orchestrating those
> bureaucratic initiatives, but it seemed like a good idea.  There may
> have been other similar efforts in other countries over the decades
> since 1981 that I don't know anything about.
> 
> In the last 40+ years, AFAIK little else has happened for testing,
> certification, or regulation of Internet technology.   Hundreds,
> perhaps thousands, of "standards" have been created by IETF and
> others, defining new protocols, algorithms, and mechanisms for use in
> the Internet.  I'm not aware of any testing or certification for any
> Internet technology today, or any way to tell is f any product or
> service I might buy actually has implemented, correctly, any
> particular "Internet Standard".
> 
> Governments can create such mechanisms around important
> infrastructures, and have done so for transportation and many others.
> IMHO they could do the same for Internet, and seem to be trying to do
> so.
> 
> But to be effective the administrators, politicians, and regulators
> need to know more about how the Internet works.   They could create
> "Conformance Labs".   They could involve organizations such as the
> Underwriters Lab in the US, CSA in Canada, CE (European Conformity) et
> al.
> 
> If they knew they could and decided they should .... Education...
> 
> Jack Haverty
> 
> On 10/12/23 12:52, Hal Murray via Nnagain wrote:
> 
>> Jack Haverty said:
>> 
>>> A few days ago I made some comments about the idea of "educating"
>>> the
>>> lawyers, politicians, and other smart, but not necessarily
>>> technically
>>> adept, decision makers.
>> 
>> That process might work.
>> 
>> Stanford has run programs on cyber security for congressional
>> staffers.
>> 
>> From 2015:
>> Congressional Staffers Headed to Stanford for Cybersecurity Training
>> 
> https://cisac.fsi.stanford.edu/news/congressional-staffers-headed-stanford-cybe
>> rsecurity-training
>> 
>>> Today I saw a news story about a recent FCC action, to mandate
>>> "nutrition
>>> labels" on Internet services offered by ISPs:
>> 
>> Is there a chicken-egg problem in this area?
>> 
>> Suppose I had a nutrition-label sort of spec for a retail ISP
>> offering.  How
>> would I know if an installation was meeting the specs?  That seems
>> to need a
>> way to collect data -- either stand alone programs or patches to
>> existing
>> programs like web browsers.
>> 
>> Would it make sense to work on those programs now?  How much could
>> we learn if
>> volunteers ran those programs and contributed data to a public data
>> base?  How
>> many volunteers would we need to get off the ground?
>> 
>> Could servers collect useful data?  Consider Zoom, YouTube, gmail,
>> downloads
>> for software updates...
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain