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

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

[Dave Taht]

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

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

[Bob McMahon]

[-- Attachment #1.1: Type: text/plain, Size: 2154 bytes --]

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.

May be a good time to simplify.

Bob

On Fri, Jul 7, 2023 at 2:25 PM Dave Taht via Make-wifi-fast <
make-wifi-fast@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@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.

[-- Attachment #1.2: Type: text/html, Size: 2985 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

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

[Aaron Wood]

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

On Sun, Jul 9, 2023 at 10:40 PM Bob McMahon via Make-wifi-fast <
make-wifi-fast@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@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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

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

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

[Bob McMahon]

[-- Attachment #1.1: Type: text/plain, Size: 7233 bytes --]

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@gmail.com> wrote:

>
>
> On Sun, Jul 9, 2023 at 10:40 PM Bob McMahon via Make-wifi-fast <
> make-wifi-fast@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@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@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@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.

[-- Attachment #1.2: Type: text/html, Size: 9402 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

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

[David Lang]

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

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@lists.bufferbloat.net>
> Reply-To: Bob McMahon <bob.mcmahon@broadcom.com>
> To: Aaron Wood <woody77@gmail.com>
> Cc: Make-Wifi-fast <make-wifi-fast@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@gmail.com> wrote:
>
>>
>>
>> On Sun, Jul 9, 2023 at 10:40 PM Bob McMahon via Make-wifi-fast <
>> make-wifi-fast@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@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@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@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>
>>
>
>

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

_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wifi-fast

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

[Bob McMahon]

[-- Attachment #1.1: Type: text/plain, Size: 11135 bytes --]

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@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@lists.bufferbloat.net>
> > Reply-To: Bob McMahon <bob.mcmahon@broadcom.com>
> > To: Aaron Wood <woody77@gmail.com>
> > Cc: Make-Wifi-fast <make-wifi-fast@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@gmail.com> wrote:
> >
> >>
> >>
> >> On Sun, Jul 9, 2023 at 10:40 PM Bob McMahon via Make-wifi-fast <
> >> make-wifi-fast@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@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@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@lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >>
> >>
> >
> >_______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@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.

[-- Attachment #1.2: Type: text/html, Size: 14171 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

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

[David Lang]

First off, I am a Huge proponent of getting the RF layout clean before anything 
else. Directional signals sound like a fantastic idea, until you realize that 
the stations you are talking to are not using directional antennas, then the 
value drops significantly (under these conditions, directional antennas create 
more hidden transmitters)

When I setup conference wifi, I take advantage of the fact that some walls block 
the wifi signals, so I can put the APs closer to the walls that block them 
without worrying about what's on the other side. I also place them on the ground 
(under the chairs) as the bodies of the attendees absorb the signal and let me 
use more APs in a room than I could get away with otherwise. I also stick to the 
standard 10MHz channels, as that lets me re-use a channel with more separation 
between APs using the same channel

And yes, I agree that it makes no sense to run an AP at a higher power level 
than the stations talking to it, so I turn the power way down.

I haven't knowingly run into the problem you describe of clients enumerating all 
available APs, but I may not have setup a high enough density of APs to run into 
the problem, can you give more info on that?

> 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.

As someone who has been looking at building a house, it's not that simple. Hard 
wired smoke detectors are only needed in some rooms, not in all, and only if the 
house is above a minimum size. Then you need different amounts of power to get 
through walls depending on how they are built.

When I setup wifi in a conference center exibit hall that's 25,000 sq ft, I 
don't believe that there are 80 smoke detectors in that one room (not to mention 
the fact that the cealing is more than 29' away, even if I'm standing directly 
under it)

Then there's the fact that not everything is inside.

David Lang

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

[Bob McMahon]

[-- Attachment #1.1: Type: text/plain, Size: 3197 bytes --]

That you can build these networks to operate well says more about you than
the guys supplying parts & equipment. Impressive real world knowledge for
sure.

Bob

On Mon, Jul 10, 2023, 4:34 PM David Lang <david@lang.hm> wrote:

> First off, I am a Huge proponent of getting the RF layout clean before
> anything
> else. Directional signals sound like a fantastic idea, until you realize
> that
> the stations you are talking to are not using directional antennas, then
> the
> value drops significantly (under these conditions, directional antennas
> create
> more hidden transmitters)
>
> When I setup conference wifi, I take advantage of the fact that some walls
> block
> the wifi signals, so I can put the APs closer to the walls that block them
> without worrying about what's on the other side. I also place them on the
> ground
> (under the chairs) as the bodies of the attendees absorb the signal and
> let me
> use more APs in a room than I could get away with otherwise. I also stick
> to the
> standard 10MHz channels, as that lets me re-use a channel with more
> separation
> between APs using the same channel
>
> And yes, I agree that it makes no sense to run an AP at a higher power
> level
> than the stations talking to it, so I turn the power way down.
>
> I haven't knowingly run into the problem you describe of clients
> enumerating all
> available APs, but I may not have setup a high enough density of APs to
> run into
> the problem, can you give more info on that?
>
> > 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.
>
> As someone who has been looking at building a house, it's not that simple.
> Hard
> wired smoke detectors are only needed in some rooms, not in all, and only
> if the
> house is above a minimum size. Then you need different amounts of power to
> get
> through walls depending on how they are built.
>
> When I setup wifi in a conference center exibit hall that's 25,000 sq ft,
> I
> don't believe that there are 80 smoke detectors in that one room (not to
> mention
> the fact that the cealing is more than 29' away, even if I'm standing
> directly
> under it)
>
> Then there's the fact that not everything is inside.
>
> David Lang
>

-- 
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.

[-- Attachment #1.2: Type: text/html, Size: 3730 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

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

[David Lang]

I'm providing the equipment (still 3800s running openwrt).

I did a presentation at LISA in 2012 and a paper in ;login going over a lot of 
this.

if you don't get the RF side right, you have no chance of having a good network 
under heavy load.

David Lang

On Mon, 10 Jul 2023, Bob McMahon wrote:

> That you can build these networks to operate well says more about you than
> the guys supplying parts & equipment. Impressive real world knowledge for
> sure.
>
> Bob
>
> On Mon, Jul 10, 2023, 4:34 PM David Lang <david@lang.hm> wrote:
>
>> First off, I am a Huge proponent of getting the RF layout clean before
>> anything
>> else. Directional signals sound like a fantastic idea, until you realize
>> that
>> the stations you are talking to are not using directional antennas, then
>> the
>> value drops significantly (under these conditions, directional antennas
>> create
>> more hidden transmitters)
>>
>> When I setup conference wifi, I take advantage of the fact that some walls
>> block
>> the wifi signals, so I can put the APs closer to the walls that block them
>> without worrying about what's on the other side. I also place them on the
>> ground
>> (under the chairs) as the bodies of the attendees absorb the signal and
>> let me
>> use more APs in a room than I could get away with otherwise. I also stick
>> to the
>> standard 10MHz channels, as that lets me re-use a channel with more
>> separation
>> between APs using the same channel
>>
>> And yes, I agree that it makes no sense to run an AP at a higher power
>> level
>> than the stations talking to it, so I turn the power way down.
>>
>> I haven't knowingly run into the problem you describe of clients
>> enumerating all
>> available APs, but I may not have setup a high enough density of APs to
>> run into
>> the problem, can you give more info on that?
>>
>>> 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.
>>
>> As someone who has been looking at building a house, it's not that simple.
>> Hard
>> wired smoke detectors are only needed in some rooms, not in all, and only
>> if the
>> house is above a minimum size. Then you need different amounts of power to
>> get
>> through walls depending on how they are built.
>>
>> When I setup wifi in a conference center exibit hall that's 25,000 sq ft,
>> I
>> don't believe that there are 80 smoke detectors in that one room (not to
>> mention
>> the fact that the cealing is more than 29' away, even if I'm standing
>> directly
>> under it)
>>
>> Then there's the fact that not everything is inside.
>>
>> David Lang
>>
>
>