[NNagain] Internet Education for Non-technorati?

[Robert McMahon]

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 at 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 at 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 at 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 at 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 at 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 at lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>>>> Nnagain mailing list
>>>>>>>> Nnagain at lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>>>> _______________________________________________
>>>>>>>> Nnagain mailing list
>>>>>>>> Nnagain at lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/nnagain/attachments/20231018/c32cfb36/attachment-0001.html>