From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DBB033B29E for ; Mon, 10 Jul 2023 15:02:59 -0400 (EDT) Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3a3ad1f39ebso3734212b6e.1 for ; Mon, 10 Jul 2023 12:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689015779; x=1691607779; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=M37jwfGknOerX4Ogmz/AfTNBeQSSE+7TT1hwDxgCBR8=; b=CMlOcGmjDzdqv98hLenbR2+W+FpFwQAauoD0PzNEYzw4lFU3235khtYdn/lIoZ394x oeJNsgj3Y4Gl8IXKhcAh+JIYKkAOix51413Z0CwDvcTn9E2wrjakYdDuEDR3YwlMsjiU spGQh6Bex/BwTDR2tj6mPMRD1JtVcncy0c9oRLCebMNWmPUvGjlAAGf9c7KNWpVvbINF bY79PJddfWiwn5A95TvGHYIIPDtLt4fbxAMV3E3Xad6XIohrKLbaMdDhgg3xiVbGp8yz 8NJYaySrOcWlZM3Rv6umBszXoSvU2gY84LsxuNBQFX3ko40mlb0SaYepTn9ROYghFJXJ tqsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689015779; x=1691607779; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=M37jwfGknOerX4Ogmz/AfTNBeQSSE+7TT1hwDxgCBR8=; b=FFB2ONofM6V+GLPxj50gP4eIbIAw4l1EVDb+j11J3RU7/18JCGv9BzG3FOrp5Fhqi4 3GXaCZpqx416R9RPlaBQONFPLtwckOTSow1pRjkNykYZ7hLtvRVfAJgXjfpCMlES8DDh ByNMLyb5SMeF6E03HOtYkWOqEFl5z7iGz9kcpeskYzPHRm7UW+t4aRFGAWCSxrrtw9UT lKt1A9KRkj6JiZqjRrcCFDS9PfkpnZ9GpR/dKluogP5h831Rc3RumzfyXWoXj58wVgGL Yv6ITfudXhj+o5mUqWeWKUzevNpBZ+5l2IbSn8/IzBq5asWrn+kKKWSInppjwUGEGBtb kweQ== X-Gm-Message-State: ABy/qLbdX25U4E4qhCFRgcsSuI9hNdh005eIyZvwRfIlujUWeEcInvbi nijtAgKo9bJaBpHTo6a0vb9LFfAXNoUBEskAxmM= X-Google-Smtp-Source: APBJJlFFL+ldTHbBuXIZks1FrlkgZF2XO9Zi8BOb06SOyLwLhGf/MJMhLeWzaPZ1rgb0oaR3yMmBtvNibDa8fkHDxYA= X-Received: by 2002:a05:6808:23d2:b0:3a1:db91:c5ef with SMTP id bq18-20020a05680823d200b003a1db91c5efmr8710161oib.23.1689015778966; Mon, 10 Jul 2023 12:02:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Wood Date: Mon, 10 Jul 2023 12:02:48 -0700 Message-ID: To: Bob McMahon Cc: Dave Taht , Make-Wifi-fast Content-Type: multipart/alternative; boundary="0000000000008681d2060026a1c3" Subject: Re: [Make-wifi-fast] I used to dream of a single wifi cpu, memory, and I/O X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2023 19:03:00 -0000 --0000000000008681d2060026a1c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 9, 2023 at 10:40=E2=80=AFPM 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=E2=80=AFPM 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=C3=A4ht 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 an= d > may contain information that is confidential, legally privileged, protect= ed > by privacy laws, or otherwise restricted from disclosure to anyone else. = If > you are not the intended recipient or the person responsible for deliveri= ng > the e-mail to the intended recipient, you are hereby notified that any us= e, > 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 --0000000000008681d2060026a1c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jul 9, 2023 at 10:40=E2=80=AF= PM Bob McMahon via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net> wrote:
<= /div>
I wonder if treating WiFi like a tra= nsceiver is the better approach, separating "the computer abstraction&= quot; 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 AP= s 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 thr= ow away 802.11 retries too and let the upper layers handle it.

Isn't this how the commercial APs t= hat 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, m= DNS routing instead of always using broadcasts, etc).=C2=A0 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).=C2=A0 I think we're maybe in a better place for that now.

Given that wifi stations must associate with APs, t= here's so=C2=A0much knowledgeable=C2=A0state that can be centrally (and= distributedly) cached and then used to move a bunch of broadcast traffic t= o single-cast.=C2=A0 With the huge difference in encoding rates between bro= adcast 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 l= ist a few times (I do find the micro-AP idea fascinating), then all "b= roadcast" traffic should hopefully become limited-transmit-power singl= e-cast, with minimal use of spectrum (both in terms of time and physical sp= ace).

One issue that I've seen with many APs i= n the same space, is that many client stations are very aggressive enumerat= ors of the available APs, much to the detriment of the operation of the sys= tem.=C2=A0 I've seen clients DoS all the available spectrum with wildca= rd probe requests and their responses, which sound like exactly the sort pr= oblems seen with ARP in very dense server racks that the vswitch and centra= l ARP server model was meant to solve: =C2=A0have a single "best"= response instead of flooding the network with responses (or requests, in t= he ARP case).

= May be=C2=A0a good time to simplify.

<= /div>
It seems like perhaps a little more hierarchy/coordination could = result in more simple operation at scale.
=C2=A0

Bob

On Fri, Jul 7, 2023 at 2:25=E2=80= =AFPM Dave Taht via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net<= /a>> wrote:
preferably using some sort of asyn= c 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.linked= in.com/feed/update/urn:li:activity:7058793910227111937/
Dave T=C3=A4ht CSO, LibreQos
_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast

This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly 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
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast
--0000000000008681d2060026a1c3--