[Cake] Re: Cake Digest, Vol 128, Issue 10

[David Lang <david@lang.hm>]

I remember hearing of people predicting such systems, but not of anyone actually 
shipping any such systems.

how would the signal get to the light bulb? networking of AC power lines is a 
thing that keeps being predicted as a 'next big thing' and while it can work, 
it's only up to a point. a combination if interference, the fact that you share 
wires with your neighbors, and just speed limits from operating over random 
wires has limited it to short-lived niche products.

As for the optical side, LEDs can be modulated at very high speeds, and 
receiving/decoding such things is not that hard, but how do you reply?

I've seen several generations of such things proposed, and then disappear for a 
few years before someone else raises the same sort of thing yet again.

David Lang

On Mon, 25 May 2026, le berger des photons wrote:

> Date: Mon, 25 May 2026 10:32:24 +0200
> From: le berger des photons <thejoff@gmail.com>
> To: cake@lists.bufferbloat.net
> Subject: [Cake] Re: Cake Digest, Vol 128, Issue 10
> 
> I remember reading about a thing and never seeing anything about it again.
> If others saw it too and I didn't just hallucinate it,  it would likely be
> people in your group.  It was a system for visible light communication
> outside of fiber optics,  just in the air.  Devices which could be
> installed by unscrewing a light bulb in a lamp, screwing this in, then
> screwing the buld back into it.  All communications were "WDS".  All
> repeaters, but so fast that there was no advantage to use an AP and client
> mode.  The people who were working on it were having to use money out of
> their own pockets and could get no corporate sponsorship.  My understanding
> was that the New World ODOR wanted to keep this from happening because they
> were afraid they wouldn't be able to control it completely and that we the
> people would use it to overthrow their pathological control over us.  so,
> did I imagine this?  I'm looking now and didn't easily find anything about
> it,  this would be normal in a world where the people who print money out
> of nothing then loan it out and interest and throw us in jail for
> criticizing them own all of the major press properties.
>
> On Mon, May 25, 2026 at 10:07 AM <cake-request@lists.bufferbloat.net> wrote:
>
>> Send Cake mailing list submissions to
>>         cake@lists.bufferbloat.net
>>
>> To subscribe or unsubscribe via email, send a message with subject or
>> body 'help' to
>>         cake-request@lists.bufferbloat.net
>>
>> You can reach the person managing the list at
>>         cake-owner@lists.bufferbloat.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Cake digest..."
>>
>> Today's Topics:
>>
>>    1. Re: [Codel] Re: [Rpm] Re: [Bloat] Re: "Fi-Wi is a new forwarding
>> plane for wireless" - Bob McMahon
>>       (Sebastian Moeller)
>>    2. Re: [Rpm] Re: [Bloat] Re: "Fi-Wi is a new forwarding plane for
>> wireless" - Bob McMahon
>>       (bob.mcmahon@umbernetworks.com)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 25 May 2026 08:58:12 +0200
>> From: Sebastian Moeller <moeller0@gmx.de>
>> Subject: [Cake] Re: [Codel] Re: [Rpm] Re: [Bloat] Re: "Fi-Wi is a new
>>         forwarding plane for wireless" - Bob McMahon
>> To: codel@lists.bufferbloat.net, Frantisek Borsik
>>         <frantisek.borsik@gmail.com>, bob.mcmahon@umbernetworks.com
>> Cc: dan <dandenson@gmail.com>, Robert McMahon
>>         <rjmcmahon@rjmcmahon.com>, David Lang <david@lang.hm>, "Livingood,
>>         Jason" <Jason_Livingood@comcast.com>, Cake List
>>         <cake@lists.bufferbloat.net>, Make-Wifi-fast
>>         <make-wifi-fast@lists.bufferbloat.net>, bloat
>>         <bloat@lists.bufferbloat.net>, Jeremy Austin via Rpm
>>         <rpm@lists.bufferbloat.net>, "Dave.seddon Ca"
>>         <dave.seddon.ca@gmail.com>, William Fisher <zzyzxr99@gmail.com>,
>> Igor
>>         Aleinikov <igor.aleinikov@adnacom.com>, Jim <jim@iniholdings.com>,
>>         Jiml <jiml@quicksmart.com>, Douglas Fairbairn
>>         <dfairbairn@megachips.com>, Thomas <thomas@monjalon.net>, Tim
>>         Odriscoll <tim.odriscoll@intel.com>, Morten <morten@broerup.com>,
>>         Sebastian Moeller <sebastian.moeller@gmail.com>, Mt Denicolo
>>         <mt.denicolo@gmail.com>, Mmcmahon01 <mmcmahon01@gmail.com>,
>> Santanu
>>         Sinha <santanusinha@yahoo.com>, Matthew <matthew@mteley.com>,
>> Koen DS
>>         <koen0607@gmail.com>, Shotaro Saito <ssaito@megachips.com>, Robin
>>         Jarry <rjarry@redhat.com>, Ehf <ehf@ehf.me>, G White
>>         <g.white@cablelabs.com>, Chunyuhu07 <chunyuhu07@gmail.com>,
>> Matthew
>>         Fischer <matthew.fischer@gmail.com>
>> Message-ID: <7455E3B4-7FB4-4D40-A900-B31151D12F6F@gmx.de>
>> Content-Type: text/plain; charset=utf-8
>>
>>
>>
>> On May 25, 2026 7:43:01 AM GMT+02:00, Frantisek Borsik <
>> frantisek.borsik@gmail.com> wrote:
>>> Hey Bob,
>>>
>>> This is all nice and all, but it really doesn't matter. The only
>> measurable
>>> term IMO we really need is this - is the setup we are using good enough
>> and
>>> delivering all we need? And the answer for ISP like Dan and many that will
>>> come "to Jesus" is sounding YES. It's here, it's cheap, it's getting
>> better.
>>
>> Not sure I fully buy this, if I understand correctly, Dan uses traffic
>> shaping to "neuter" WiFi from its worst self congestion tendencies... that
>> is a clever way to work around clear short comings in modern WiFi not
>> evidence that modern WiFi has no issues...
>>
>>>
>>> You will get your evidence and then what? When (and big iF) Fi-Wi will
>>> materialize, we will have Wi-Fi 8
>>> <
>> https://www.linkedin.com/feed/update/urn:li:activity:7460998580456116224/>
>>> for those interested in chasing marginal improvements and the latest
>> thing.
>>
>> That is the 3GPP playbook, always overpromise for the coming generation
>> N+1 and once that materilalizes and typically under-delivers roll-over the
>> unfulfilled promises simply into N+2, maybe add a few more claims... Sure
>> fitting for the latexstage capitalusm we find ourselves in, but let's not
>> get fooled by marketing promises and judge WiFi8 once it exists by its
>> merits/performance, please.
>>
>>> Jonathan Morton will deliver his improvement on CAKE, we might even get
>>> into microsecond territory.
>>
>> Last time I researched his deltic approach it looked very much not going
>> into the microsecond territory, I remember 25ms as latency target
>> somehow... 25ms is certainly not bad, and not high-latency, but seems
>> different from ultra-low-latency approaches. So I might have missed some
>> interesting development, if you have a link you could share to get me up to
>> speed again, I would be grateful.
>>
>>> There will be FQ-PIE, PURPLE CAKE, HTB-MQ (to
>>> supplement CAKE-MQ)...
>>>
>>> Anyway, you will like this:
>>>
>> https://arstechnica.com/gadgets/2017/02/going-hands-on-and-behind-the-scenes-at-the-plume-wi-fi-hq/
>>>
>>> Plume used to do this, you will have your Fi-Wi house test bed up and
>>> running, soon. Let's have fun and do another round of the good ole
>>> Wi-Fi/mesh router rumble:
>>>
>>>
>> https://arstechnica.com/gadgets/2016/09/the-router-rumble-ars-diy-build-faces-better-tests-tougher-competition/
>>>
>> https://arstechnica.com/gadgets/2016/12/review-comparing-google-wifi-to-other-mesh-networking-heavyweights/
>>>
>>> Maybe Jim and Ars Technica would be interested in it.
>>>
>>>
>>> All the best,
>>>
>>> Frank
>>>
>>> Frantisek (Frank) Borsik
>>>
>>>
>>> *In loving memory of Dave Täht: *1965-2025
>>>
>>> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
>>>
>>>
>>> https://www.linkedin.com/in/frantisekborsik
>>>
>>> Signal, Telegram, WhatsApp: +421919416714
>>>
>>> iMessage, mobile: +420775230885
>>>
>>> Skype: casioa5302ca
>>>
>>> frantisek.borsik@gmail.com
>>>
>>>
>>> On Sun, May 24, 2026 at 11:57 PM <bob.mcmahon@umbernetworks.com> wrote:
>>>
>>>> Hi Frank,
>>>>
>>>> The question needs to be framed in measurable terms.
>>>>
>>>> The systems you named operate at different layers than the 802.11
>> MAC/PHY
>>>> layer where TXOP allocation, retries, EDCA contention, AMPDU behavior,
>> and
>>>> airtime utilization occur throughout the building. batman-adv routes
>>>> between mesh nodes. CAKE and FQ-CoDel operate on IP-layer queues. QoE
>>>> middle-boxes operate from the WAN/IP side.
>>>>
>>>> So the question is whether IP-layer AQMs or WAN-side QoE systems affect
>>>> measurable 802.11 MAC/PHY behavior under load.
>>>>
>>>> If they do, the predicted MAC/PHY effects would include:
>>>>
>>>>    - lower failed TXOP percentage
>>>>    - lower retransmission airtime fraction
>>>>    - improved AMPDU completion efficiency
>>>>    - higher payload delivered per TXOP
>>>>    - lower AMPDU truncation frequency
>>>>    - reduced EDCA wait distributions
>>>>    - improved airtime utilization
>>>>    - reduced service-time variance
>>>>    - changed MCS distributions across stations under realistic spatial
>>>>    topology, particularly at coverage edges and where multiple APs or
>> RRHs are
>>>>    candidates for node selection
>>>>
>>>> That is the measurement gap I am pointing at. The industry has extensive
>>>> 802.11 feature lists and marketing claims, with comparatively little
>> open
>>>> tooling to falsify what those actually do to building wide 802.11
>> MAC/PHY
>>>> behavior under real multi-client, multi-AP load.
>>>>
>>>> I developed and still maintain iperf2 because throughput alone has
>> proven
>>>> an insufficient measurement model for network behavior, e.g. latencies
>> and
>>>> responsiveness under load. Features added to iperf2 include:
>>>>
>>>>    - trip-times
>>>>    - bounceback testing
>>>>    - one-way IP packet timing measurements
>>>>    - packet-level latency histograms
>>>>    - message-level (TCP write/read completion) latency histograms
>>>>    - responsiveness under load measurements
>>>>    - enhanced per-interval reporting
>>>>    - CWND reporting
>>>>    - RTT reporting
>>>>    - bytes/packets in-flight reporting
>>>>    - TCP retransmission reporting
>>>>    - TCP congestion-control selection (CUBIC, BBR, Prague, etc.)
>>>>    - udp-l4s including CE counters and durations
>>>>    - isochronous traffic generation
>>>>    - socket-layer pacing via SO_MAX_PACING_RATE
>>>>    - token-bucket write-rate control
>>>>    - Markov-chain packet-size generation
>>>>    - UDP latency/jitter analysis
>>>>    - multicast testing
>>>>
>>>> Those measurements operate above the 802.11 MAC/PHY. The missing layer
>>>> remains open 802.11 MAC/PHY telemetry, which is what I'm building now.
>>>>
>>>> This measurement standard should apply equally to any claim from any
>>>> architecture, including Fi-Wi.
>>>>
>>>> The question becomes: does centralized MAC telemetry and coordinated
>>>> airtime control affect measurable 802.11 MAC/PHY behavior under load
>>>> relative to autonomous AP operation?
>>>>
>>>> Measure the same MAC/PHY metrics under equivalent topology, offered
>> load,
>>>> and client mix. If those measurements do not improve relative to
>> baseline,
>>>> the architectural claim of Fi-Wi fails. We won't know until Fi-Wi is
>>>> designed, built, deployed and measured at many different locations. The
>>>> theoretical case is strong.  Centralized scheduling, joint optimization,
>>>> and observability all argue for it. The design and measurements are the
>>>> next steps. Then we'll see based on evidence.
>>>>
>>>> Bob
>>>>
>>>> Technically, Betamax was superior to VHS, and yet...
>>>>
>>>> If we would be talking about FiWi pre-jump from Wi-Fi 5 to Wi-Fi6/E/7, I
>>>> would even try to do my best and ignore https://fastgood.cheap.
>>>> But we are not there, for better or for worse.
>>>>
>>>> ISPs like Dan that use Wi-Fi 6 (with mesh, especially based on
>> batman-adv
>>>> and FQ-CoDel / CAKE) and above at customer premises and Quality of
>>>> Experience middle-box on their last-mile, while providing good, personal
>>>> customer service (not some crappy outsourcing of it to India or "AI")
>> will
>>>> be hard to beat, even for a big telco/ISP offering cheaper price. Yes,
>> some
>>>> people will leave but the most of them will be coming back.
>>>>
>>>> This is, believe it or not, not a high bar to jump over, even though not
>>>> many ISPs are getting it already. We all know that more or less:
>> "Bandwidth
>>>> is a lie, Bandwidth is dead," so it's coming. They will be throwing more
>>>> bandwidth on it for some time, but we will be getting from "innovators"
>> to
>>>> "early adopters" soon and then, all we need is just that "crossing the
>>>> chasm."
>>>>
>>>> Despite all the difficulties, it will be faster and cheaper - also "good
>>>> enough," than FiWi. Or rather, it's here already, it's just not evenly
>>>> distributed.
>>>> There might be some good niche use case for FiWi, though, once it will
>>>> mature and get there.
>>>>
>>>> All the best,
>>>>
>>>>
>>>> Frank
>>>>
>>>>
>>>>
>>>> Frantisek (Frank) Borsik
>>>>
>>>>
>>>>
>>>> *In loving memory of Dave Täht: *1965-2025
>>>>
>>>> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
>>>>
>>>>
>>>>
>>>> https://www.linkedin.com/in/frantisekborsik
>>>>
>>>> Signal, Telegram, WhatsApp: +421919416714
>>>>
>>>> iMessage, mobile: +420775230885
>>>>
>>>> Skype: casioa5302ca
>>>>
>>>> frantisek.borsik@gmail.com
>>>>
>>>> On Sun, May 24, 2026 at 2:12 AM dan <dandenson@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Sat, May 23, 2026 at 10:36 AM <bob.mcmahon@umbernetworks.com> wrote:
>>>>
>>>>> I don't have arguments on the technical bits of your reply.
>>>>
>>>> The industry hasn't provided open source tools to analyze 802.11
>> properly.
>>>> The proprietary ones are tightly coupled to chip firmware, owned by
>> 802.11
>>>> vendors, and not for sale.
>>>>
>>>> You've built solid networks, especially given how little 802.11
>> MAC-layer
>>>> and MCS observability current tooling exposes. I hope to make open
>> source
>>>> 802.11 MAC telemetry tools available sooner rather than later. These
>> will
>>>> run on both an ESP32-C5 and an RPi5. The inexpensive ESP32 allows
>> monitors
>>>> to be placed throughout a venue at low cost.
>>>>
>>>> A key issue is what's being measured. Your deployment data is a capacity
>>>> analysis. Once baseline capacity is adequate, user experience is driven
>> by
>>>> tail latency and service-time variance rather than throughput. A network
>>>> can saturate aggregate throughput while still showing large service-time
>>>> variance and long per-flow tails under contention. These are different
>>>> measurements.
>>>>
>>>> And CODEL and CAKE are IP-layer mechanisms. They don't operate on 802.11
>>>> TXOPs or airtime sojourn, which is where the contention and service-time
>>>> variance actually live. AQL is closer. It operates on airtime at the
>>>> driver/firmware boundary, but it's still per-AP. There's no coordination
>>>> across APs and no MAC telemetry exposed upward.
>>>>
>>>> Slide 6 of my DPDK Summit Stockholm talk lays out the layering:
>>>> https://www.umbernetworks.com/DPDK_WiFi_Stockholm_Pres.html
>>>>
>>>> Check out iperf2's advanced features around --bounceback, --trip-times,
>>>> and --histograms. These are available as open source. Man page:
>>>> https://iperf2.sourceforge.io/iperf-manpage.html
>>>>
>>>> I'll try to respond with some metrics soon. My rig is down at the
>> moment,
>>>> so give me a few days.
>>>>
>>>> Bob
>>>>
>>>>
>>>> I agree.  However, I'm not actually just measuring throughput, but
>> running
>>>> latency sensitive applications without issues.  Frank might attest to my
>>>> efforts to reduce latency and I routinely share data on lqos (and
>> another
>>>> QoE product's) TCP measurements for latency and among QoE users, I
>> believe
>>>> my network is top 1% in latency and jitter and in the WISP space.
>>>> Obviously I'm not going to compete with XGSPON operators.. (though I'm
>> only
>>>> measuring TCP because that's the 'easiest' to measure passively
>>>> practically).  While this is not an engineering adequate benchmark, if
>> my
>>>> VoIP handsets work over wireless then the wireless is good is a very
>>>> reasonable latency, jitter, loss argument.  And I run a few brands of
>> WiFi
>>>> based VoIP phones (Fanvill Wxxx series, Yealink Wxx and AXxx series).
>>>> Similarly, if the sonos works and is in sync, the wifi is good.
>>>>
>>>> As a service company and as a user, I don't really care so much where
>> the
>>>> goodness is in the system, mac layer or IP having cake work it's magic.
>>>> Basically running an AP on OFMDA (as much as possible) and well under
>> the
>>>> 'red line' capacity delivers great results on WiFi7 radios (and some
>> WiFi6
>>>> radios).  I have no doubt that FiWi could get more of the theoretical
>>>> throughput delivered at the mac layer.
>>>>
>>>> Deliverables are all that matter to me and I think to buyers and users.
>>>> Benchmarks test deliverables which is great and I'm a routing iperf*
>> user.
>>>> It's engineering's problem to develop the next tech *AND* solicit
>> funding
>>>> to do so.
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Codel mailing list -- codel@lists.bufferbloat.net
>>> To unsubscribe send an email to codel-leave@lists.bufferbloat.net
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sun, 24 May 2026 14:57:25 -0700
>> From: bob.mcmahon@umbernetworks.com
>> Subject: [Cake] Re: [Rpm] Re: [Bloat] Re: "Fi-Wi is a new forwarding
>>         plane for wireless" - Bob McMahon
>> To: Frantisek Borsik <frantisek.borsik@gmail.com>
>> Cc: dan <dandenson@gmail.com>, Robert McMahon
>>         <rjmcmahon@rjmcmahon.com>, David Lang <david@lang.hm>, "Livingood,
>>         Jason" <Jason_Livingood@comcast.com>, Cake List
>>         <cake@lists.bufferbloat.net>, Make-Wifi-fast
>>         <make-wifi-fast@lists.bufferbloat.net>, bloat
>>         <bloat@lists.bufferbloat.net>, Jeremy Austin via Rpm
>>         <rpm@lists.bufferbloat.net>, codel@lists.bufferbloat.net,
>> "Dave.seddon
>>         Ca" <dave.seddon.ca@gmail.com>, William Fisher <zzyzxr99@gmail.com
>>> ,
>>         Igor Aleinikov <igor.aleinikov@adnacom.com>, Jim
>>         <jim@iniholdings.com>, Jiml <jiml@quicksmart.com>, Douglas
>> Fairbairn
>>         <dfairbairn@megachips.com>, Thomas <thomas@monjalon.net>, Tim
>>         Odriscoll <tim.odriscoll@intel.com>, Morten <morten@broerup.com>,
>>         Sebastian Moeller <sebastian.moeller@gmail.com>, Mt Denicolo
>>         <mt.denicolo@gmail.com>, Mmcmahon01 <mmcmahon01@gmail.com>,
>> Santanu
>>         Sinha <santanusinha@yahoo.com>, Matthew <matthew@mteley.com>,
>> Koen DS
>>         <koen0607@gmail.com>, Shotaro Saito <ssaito@megachips.com>, Robin
>>         Jarry <rjarry@redhat.com>, Ehf <ehf@ehf.me>, G White
>>         <g.white@cablelabs.com>, Chunyuhu07 <chunyuhu07@gmail.com>,
>> Matthew
>>         Fischer <matthew.fischer@gmail.com>
>> Message-ID: <055e42685cddfa4c1a4ff4da089996eb@umbernetworks.com>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> Hi Frank,
>>
>> The question needs to be framed in measurable terms.
>>
>> The systems you named operate at different layers than the 802.11
>> MAC/PHY layer where TXOP allocation, retries, EDCA contention, AMPDU
>> behavior, and airtime utilization occur throughout the building.
>> batman-adv routes between mesh nodes. CAKE and FQ-CoDel operate on
>> IP-layer queues. QoE middle-boxes operate from the WAN/IP side.
>>
>> So the question is whether IP-layer AQMs or WAN-side QoE systems affect
>> measurable 802.11 MAC/PHY behavior under load.
>>
>> If they do, the predicted MAC/PHY effects would include:
>>
>>         * lower failed TXOP percentage
>>         * lower retransmission airtime fraction
>>         * improved AMPDU completion efficiency
>>         * higher payload delivered per TXOP
>>         * lower AMPDU truncation frequency
>>         * reduced EDCA wait distributions
>>         * improved airtime utilization
>>         * reduced service-time variance
>>         * changed MCS distributions across stations under realistic
>> spatial
>> topology, particularly at coverage edges and where multiple APs or RRHs
>> are candidates for node selection
>>
>> That is the measurement gap I am pointing at. The industry has extensive
>> 802.11 feature lists and marketing claims, with comparatively little
>> open tooling to falsify what those actually do to building wide 802.11
>> MAC/PHY behavior under real multi-client, multi-AP load.
>>
>> I developed and still maintain iperf2 because throughput alone has
>> proven an insufficient measurement model for network behavior, e.g.
>> latencies and responsiveness under load. Features added to iperf2
>> include:
>>
>>         * trip-times
>>         * bounceback testing
>>         * one-way IP packet timing measurements
>>         * packet-level latency histograms
>>         * message-level (TCP write/read completion) latency histograms
>>         * responsiveness under load measurements
>>         * enhanced per-interval reporting
>>         * CWND reporting
>>         * RTT reporting
>>         * bytes/packets in-flight reporting
>>         * TCP retransmission reporting
>>         * TCP congestion-control selection (CUBIC, BBR, Prague, etc.)
>>         * udp-l4s including CE counters and durations
>>         * isochronous traffic generation
>>         * socket-layer pacing via SO_MAX_PACING_RATE
>>         * token-bucket write-rate control
>>         * Markov-chain packet-size generation
>>         * UDP latency/jitter analysis
>>         * multicast testing
>>
>> Those measurements operate above the 802.11 MAC/PHY. The missing layer
>> remains open 802.11 MAC/PHY telemetry, which is what I'm building now.
>>
>> This measurement standard should apply equally to any claim from any
>> architecture, including Fi-Wi.
>>
>> The question becomes: does centralized MAC telemetry and coordinated
>> airtime control affect measurable 802.11 MAC/PHY behavior under load
>> relative to autonomous AP operation?
>>
>> Measure the same MAC/PHY metrics under equivalent topology, offered
>> load, and client mix. If those measurements do not improve relative to
>> baseline, the architectural claim of Fi-Wi fails. We won't know until
>> Fi-Wi is designed, built, deployed and measured at many different
>> locations. The theoretical case is strong.  Centralized scheduling,
>> joint optimization, and observability all argue for it. The design and
>> measurements are the next steps. Then we'll see based on evidence.
>>
>> Bob
>>
>>> Technically, Betamax was superior to VHS, and yet...
>>>
>>> If we would be talking about FiWi pre-jump from Wi-Fi 5 to Wi-Fi6/E/7,
>>> I would even try to do my best and ignore https://fastgood.cheap.
>>> But we are not there, for better or for worse.
>>>
>>> ISPs like Dan that use Wi-Fi 6 (with mesh, especially based on
>>> batman-adv and FQ-CoDel / CAKE) and above at customer premises and
>>> Quality of Experience middle-box on their last-mile, while providing
>>> good, personal customer service (not some crappy outsourcing of it to
>>> India or "AI") will be hard to beat, even for a big telco/ISP offering
>>> cheaper price. Yes, some people will leave but the most of them will be
>>> coming back.
>>>
>>> This is, believe it or not, not a high bar to jump over, even though
>>> not many ISPs are getting it already. We all know that more or less:
>>> "Bandwidth is a lie, Bandwidth is dead," so it's coming. They will be
>>> throwing more bandwidth on it for some time, but we will be getting
>>> from "innovators" to "early adopters" soon and then, all we need is
>>> just that "crossing the chasm."
>>>
>>> Despite all the difficulties, it will be faster and cheaper - also
>>> "good enough," than FiWi. Or rather, it's here already, it's just not
>>> evenly distributed.
>>> There might be some good niche use case for FiWi, though, once it will
>>> mature and get there.
>>>
>>> All the best,
>>>
>>> Frank
>>>
>>> Frantisek (Frank) Borsik
>>>
>>> In loving memory of Dave Täht: 1965-2025
>>>
>>> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
>>>
>>> https://www.linkedin.com/in/frantisekborsik
>>>
>>> Signal, Telegram, WhatsApp: +421919416714
>>>
>>> iMessage, mobile: +420775230885
>>>
>>> Skype: casioa5302ca
>>>
>>> frantisek.borsik@gmail.com
>>>
>>> On Sun, May 24, 2026 at 2:12 AM dan <dandenson@gmail.com> wrote:
>>>
>>> On Sat, May 23, 2026 at 10:36 AM <bob.mcmahon@umbernetworks.com> wrote:
>>>
>>>> I don't have arguments on the technical bits of your reply.
>>>
>>> The industry hasn't provided open source tools to analyze 802.11
>>> properly. The proprietary ones are tightly coupled to chip firmware,
>>> owned by 802.11 vendors, and not for sale.
>>>
>>> You've built solid networks, especially given how little 802.11
>>> MAC-layer and MCS observability current tooling exposes. I hope to make
>>> open source 802.11 MAC telemetry tools available sooner rather than
>>> later. These will run on both an ESP32-C5 and an RPi5. The inexpensive
>>> ESP32 allows monitors to be placed throughout a venue at low cost.
>>>
>>> A key issue is what's being measured. Your deployment data is a
>>> capacity analysis. Once baseline capacity is adequate, user experience
>>> is driven by tail latency and service-time variance rather than
>>> throughput. A network can saturate aggregate throughput while still
>>> showing large service-time variance and long per-flow tails under
>>> contention. These are different measurements.
>>>
>>> And CODEL and CAKE are IP-layer mechanisms. They don't operate on
>>> 802.11 TXOPs or airtime sojourn, which is where the contention and
>>> service-time variance actually live. AQL is closer. It operates on
>>> airtime at the driver/firmware boundary, but it's still per-AP. There's
>>> no coordination across APs and no MAC telemetry exposed upward.
>>>
>>> Slide 6 of my DPDK Summit Stockholm talk lays out the layering:
>>> https://www.umbernetworks.com/DPDK_WiFi_Stockholm_Pres.html
>>>
>>> Check out iperf2's advanced features around --bounceback, --trip-times,
>>> and --histograms. These are available as open source. Man page:
>>> https://iperf2.sourceforge.io/iperf-manpage.html
>>>
>>> I'll try to respond with some metrics soon. My rig is down at the
>>> moment, so give me a few days.
>>>
>>> Bob
>>>
>>> I agree.  However, I'm not actually just measuring throughput, but
>>> running latency sensitive applications without issues.  Frank might
>>> attest to my efforts to reduce latency and I routinely share data on
>>> lqos (and another QoE product's) TCP measurements for latency and among
>>> QoE users, I believe my network is top 1% in latency and jitter and in
>>> the WISP space.  Obviously I'm not going to compete with XGSPON
>>> operators.. (though I'm only measuring TCP because that's the 'easiest'
>>> to measure passively practically).  While this is not an engineering
>>> adequate benchmark, if my VoIP handsets work over wireless then the
>>> wireless is good is a very reasonable latency, jitter, loss argument.
>>> And I run a few brands of WiFi based VoIP phones (Fanvill Wxxx series,
>>> Yealink Wxx and AXxx series).  Similarly, if the sonos works and is in
>>> sync, the wifi is good.
>>>
>>> As a service company and as a user, I don't really care so much where
>>> the goodness is in the system, mac layer or IP having cake work it's
>>> magic.  Basically running an AP on OFMDA (as much as possible) and well
>>> under the 'red line' capacity delivers great results on WiFi7 radios
>>> (and some WiFi6 radios).  I have no doubt that FiWi could get more of
>>> the theoretical throughput delivered at the mac layer.
>>>
>>> Deliverables are all that matter to me and I think to buyers and users.
>>>  Benchmarks test deliverables which is great and I'm a routing iperf*
>>> user.  It's engineering's problem to develop the next tech *AND*
>>> solicit funding to do so.
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Cake mailing list -- cake@lists.bufferbloat.net
>> To unsubscribe send an email to cake-leave@lists.bufferbloat.net
>>
>>
>> ------------------------------
>>
>> End of Cake Digest, Vol 128, Issue 10
>> *************************************
>>
> _______________________________________________
> Cake mailing list -- cake@lists.bufferbloat.net
> To unsubscribe send an email to cake-leave@lists.bufferbloat.net