[Make-wifi-fast] I used to dream of a single wifi cpu, memory, and I/O

[Bob McMahon]

Hi David,

The proposal with FiWi is to use pt2pt radio paths and spatial
separation, free space path loss is an advantage. Stop blasting energy to
thousands of square feet, raising the noise floor for no good reasons. I
think of it like irrigation sprinklers or led task lighting or electric
circuits. We think radios & spectrum as scarce and that assumption is going
away quickly. A current WiFi die can hold 100s of CMOS radios and not sure
the PHYs (it's somethign I need to check.) The front ends are tricky but those
are going up too.
<https://www.eenewseurope.com/en/worlds-first-rf-front-end-module-with-filter-for-wifi-7-access-points/>
There are currently 3 FEs per AP as an example and power and space is going
down per every iteration. There is no reason to send energy more than 29'
as that's the distance per fire code that a human has to be from a working
smoke detector. and in many cities, one can't sell a house without a
hard-wired, battery backed up, and inter connected smoke detectors.  Might
as well put in 2.5Gb/s per spatial stream at 30' RRHs too, at less than 2-3
watts each including the fiber runs.

Time to simplify the geography problem. The AP/STA power imbalance is a
major design flaw as bad as bufferbloat. Every standard iteration is
effectively engineering bloat. I think we're at a point to reassess and
simplify everywhere and change the Titanic's direction.

Bob

On Mon, Jul 10, 2023 at 2:29 PM David Lang <david at lang.hm> wrote:

> you can't just treat wifi as any other transport and have things work
> well.
> There is too much overhead in sending packets to any destination. Every
> other
> transport has effectively zero cost to send a packet to A a packet to B
> and then
> another packet to A. In wifi, you can send hundreds (if not thousands) of
> packets to A in the time that it will take you to send a packet to B. As a
> result, you need to queue things per destination in ways that you don't
> for
> anything else.
>
> To see how this works, look at the time that you wait to see if the
> channel is
> used, plus the time needed to transmit the packet header (at a low
> bitrate), and
> then the time needed to send the actual data (at a high bitrate)
>
> see how much actual data you could send to one station in the time that it
> would
> take to send two 64 byte packets to two different stations (ignoring
> MU-MIMO for
> the moment)
>
> Also, as a practical matter, under most conditions, almost all your
> traffic is
> going to be wifi <-> wired, very little is wifi <-> wifi (IoT could have
> changed
> this, but in practice, IoT is IoT <-> cloud <-> user rather than IoT <->
> user)
>
> David Lang
>
>
> On Mon, 10 Jul 2023, Bob McMahon via Make-wifi-fast wrote:
>
> > Date: Mon, 10 Jul 2023 13:47:32 -0700
> > From: Bob McMahon via Make-wifi-fast <
> make-wifi-fast at lists.bufferbloat.net>
> > Reply-To: Bob McMahon <bob.mcmahon at broadcom.com>
> > To: Aaron Wood <woody77 at gmail.com>
> > Cc: Make-Wifi-fast <make-wifi-fast at lists.bufferbloat.net>
> > Subject: Re: [Make-wifi-fast] I used to dream of a single wifi cpu,
> memory,
> >     and I/O
> >
> > I think of it as a micro translational bridge, i.e. get 802.11 to 802.3
> to
> > standard forwarding silicon (though some call it a "skinny" AP.) The "AP
> > split" is between managing MAC/frame things and MAC/PHY things. Try to
> > minimize the PHY knobs so the RRH can self-manage what's not been preset
> by
> > the installer. Remove the sw config stuff on the RRH too as it just adds
> > OPEX costs for limited benefit.
> >
> > Others see it as "bluetooth p2p" model applied to WiFi,  but radio
> pairings
> > at low latency, low power and high throughputs - though this mental model
> > has some flaws too.
> >
> > I think the EAP architecture is woefully broken. "Centralizing the
> > controllers" of distribution management isn't the same as *eliminating &
> > mitigating the need to manage complex distributed things.  *Linux
> computers
> > are complex, distributed things and don't belong in homes unless the home
> > is owned by a network and sys admin ;)
> >
> > The closest models seem to be ECPRI used by 5G towers or the distributed
> > access architecture (DAA) of HFC.
> >
> > FiWi will blow those out of the water by my judgment - though those are
> OSP
> > things and FiWi will start as an inside plant thing.  We just have to
> > figure out how to motivate humans as engineers & marketing experts to
> start
> > moving in this direction. It seems like a no brainer that consumers will
> > want to show off their "fiber" - inside plant, future proof, life support
> > capable, resilient to failures, & something that increases the property
> or
> > asset value of their primary investment. Maybe FTTH shouldn't be marketed
> > as "Fiber to the Home" but "Fiber through the Home" with no more wires
> for
> > comm anywhere?
> >
> > Bob
> >
> >
> >
> >
> > On Mon, Jul 10, 2023 at 12:02 PM Aaron Wood <woody77 at gmail.com> wrote:
> >
> >>
> >>
> >> On Sun, Jul 9, 2023 at 10:40 PM Bob McMahon via Make-wifi-fast <
> >> make-wifi-fast at lists.bufferbloat.net> wrote:
> >>
> >>> I wonder if treating WiFi like a transceiver is the better approach,
> >>> separating "the computer abstraction" from the remote radio head.
> >>>
> >>> Then it's a RF Front End(s) / CMOS Radios / PHY(s) / 802.11 MAC(s)
> >>> (lower) / 802.3 PAM4 / 100G SERDES / 4 1x25G VCSELs. Pluggable like an
> SFP.
> >>>
> >>> The virtualized APs could support at least 10 and maybe 100s of these
> via
> >>> merchant switching silicon and could be kilometers away. The MACs lower
> >>> could be simplified to dual queue a la L4S. No need for 4 AC queues per
> >>> MAC. Might be able to throw away 802.11 retries too and let the upper
> >>> layers handle it.
> >>>
> >>
> >> Isn't this how the commercial APs that use a combined
> >> backhaul/control-plane operate?
> >>
> >> I've often wanted to use something like OpenVSwitch to combine all the
> >> layer-2 broadcast domains without actually making them a single
> broadcast
> >> domain (central ARP responder/router, multicast-to-singlecast
> conversion,
> >> mDNS routing instead of always using broadcasts, etc).  I know that we
> were
> >> looking at that with CeroWRT, early on, using routing between separate
> >> subnets, but that required a bunch of proxies that never seemed to
> really
> >> work as well as I wanted (or I wasn't very good at getting them set up
> >> correctly).  I think we're maybe in a better place for that now.
> >>
> >> Given that wifi stations must associate with APs, there's so much
> >> knowledgeable state that can be centrally (and distributedly) cached and
> >> then used to move a bunch of broadcast traffic to single-cast.  With the
> >> huge difference in encoding rates between broadcast and singlecast
> traffic,
> >> especially as the number of STAs increases, it seems like it would be
> very
> >> beneficial.
> >>
> >> And if you were in the 1:1 AP<->STA situation that has floated across
> this
> >> list a few times (I do find the micro-AP idea fascinating), then all
> >> "broadcast" traffic should hopefully become limited-transmit-power
> >> single-cast, with minimal use of spectrum (both in terms of time and
> >> physical space).
> >>
> >> One issue that I've seen with many APs in the same space, is that many
> >> client stations are very aggressive enumerators of the available APs,
> much
> >> to the detriment of the operation of the system.  I've seen clients DoS
> all
> >> the available spectrum with wildcard probe requests and their responses,
> >> which sound like exactly the sort problems seen with ARP in very dense
> >> server racks that the vswitch and central ARP server model was meant to
> >> solve:  have a single "best" response instead of flooding the network
> with
> >> responses (or requests, in the ARP case).
> >>
> >> May be a good time to simplify.
> >>>
> >>
> >> It seems like perhaps a little more hierarchy/coordination could result
> in
> >> more simple operation at scale.
> >>
> >>
> >>>
> >>> Bob
> >>>
> >>> On Fri, Jul 7, 2023 at 2:25 PM Dave Taht via Make-wifi-fast <
> >>> make-wifi-fast at lists.bufferbloat.net> wrote:
> >>>
> >>>> preferably using some sort of async circuitry for minimum interference
> >>>> and power consumption. I figured, oh, 256MB would be more than enough
> >>>> for a 10Gbit router.
> >>>>
> >>>> Instead, we can now layer 64GB on die.
> >>>>
> >>>>
> https://blocksandfiles.com/2023/07/05/3d-stacked-dram-and-processor-cube/
> >>>>
> >>>> --
> >>>> Podcast:
> >>>>
> https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
> >>>> Dave Täht CSO, LibreQos
> >>>> _______________________________________________
> >>>> Make-wifi-fast mailing list
> >>>> Make-wifi-fast at lists.bufferbloat.net
> >>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >>>
> >>>
> >>> This electronic communication and the information and any files
> >>> transmitted with it, or attached to it, are confidential and are
> intended
> >>> solely for the use of the individual or entity to whom it is addressed
> and
> >>> may contain information that is confidential, legally privileged,
> protected
> >>> by privacy laws, or otherwise restricted from disclosure to anyone
> else. If
> >>> you are not the intended recipient or the person responsible for
> delivering
> >>> the e-mail to the intended recipient, you are hereby notified that any
> use,
> >>> copying, distributing, dissemination, forwarding, printing, or copying
> of
> >>> this e-mail is strictly prohibited. If you received this e-mail in
> error,
> >>> please return the e-mail to the sender, delete it from your computer,
> and
> >>> destroy any printed copy of it.
> >>> _______________________________________________
> >>> Make-wifi-fast mailing list
> >>> Make-wifi-fast at lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >>
> >>
> >
> >_______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20230710/c8e7a320/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20230710/c8e7a320/attachment-0001.bin>