Beyond the NAT: The Hidden Cost of Wi-Fi
A while ago I wrote about bufferbloat, BBR and why modern internet connections can still feel slow even when bandwidth itself is excellent.
Previous article:
The core idea behind that article was fairly simple: throughput and responsiveness are completely different things. A connection can move huge amounts of data while still feeling unstable because latency, queue growth and congestion quietly destroy interactive workloads.
After spending more time debugging home networks, pfSense boxes, OpenWRT access points and random latency spikes that only appear at certain hours of the day, I started noticing another pattern that appears surprisingly often: many internet problems people blame on their ISP are actually local Wi-Fi problems.
This becomes difficult to diagnose because the network still mostly works.
Streaming continues functioning. Websites still open. Speedtests still look good. Meanwhile latency-sensitive workloads begin behaving strangely. SSH sessions occasionally freeze for a few hundred milliseconds, Discord calls briefly sound robotic, games spike unpredictably and remote desktop sessions start feeling inconsistent despite the WAN connection itself looking perfectly healthy.
Modern fiber connections became so fast that in many homes the bottleneck quietly moved somewhere else entirely. The WAN link stopped being the weakest part of the stack. The local RF environment became the unstable component instead.
I have seen situations where perfectly healthy fiber connectivity was blamed for weeks while the real issue ended up being a poorly positioned mesh node quietly destroying latency through retransmissions and roaming instability. Another memorable case involved a cheap wireless camera aggressively uploading footage to the cloud every evening and increasing latency across the entire apartment once neighboring networks became active.
The internet itself was fine.
The wireless environment around it was not.
Wi-Fi Behaves Very Differently From Ethernet
Modern switched Ethernet is stable enough that most people stopped thinking about networking at the physical layer years ago. Once a cable is connected and the link negotiates correctly, the environment itself rarely changes unless there is actual hardware failure, a damaged cable or some extremely questionable switch behavior.
Wi-Fi behaves differently because the medium itself constantly changes.
The access point is not communicating through an isolated cable. It is operating inside a shared RF environment where every nearby device influences communication quality in some way. Signal strength changes depending on walls, reflections, interference and distance. Neighboring APs compete for airtime. Cheap IoT devices transmit inefficiently. Bluetooth devices introduce additional noise. Client roaming behavior varies wildly between vendors.
Even microwave ovens still occasionally appear in debugging stories, which remains mildly offensive considering the year is 2026.
Under the hood, Wi-Fi relies heavily on mechanisms like CSMA/CA, where devices attempt to avoid transmitting simultaneously inside a shared medium.
This means every client connected to the AP influences the others in some way.
That is one of the most important differences between Wi-Fi and Ethernet, and it explains a large percentage of the strange behavior people experience on modern home networks.
Consumer Networking Marketing Created Strange Expectations
One of the more unfortunate things consumer networking marketing did over the last decade was teaching people to evaluate network quality almost entirely through throughput numbers.
Router boxes now mostly advertise:
- maximum bandwidth
- Wi-Fi generation
- gaming acceleration
- AI mesh optimization
- increasingly absurd antenna designs
Meanwhile the actual problems users complain about are usually:
- latency spikes
- jitter
- retransmissions
- unstable roaming
- queueing delay
- inconsistent responsiveness
This creates situations where somebody upgrades from one expensive router to another even more expensive router and notices almost no practical improvement because the actual issue was overloaded channels, poor AP placement, excessive airtime contention or bad queue management.
A network that maintains stable latency under load often feels dramatically better than one that simply produces impressive bandwidth numbers during a speedtest.
Airtime Matters More Than Most People Realize
One of the least intuitive aspects of Wi-Fi is that devices are not really sharing bandwidth fairly. They are sharing airtime.
This distinction matters because clients with poor signal quality usually transmit at lower modulation rates. A device operating with weak signal-to-noise ratio occupies the medium for longer periods of time while transmitting the same amount of data.
Something like this happens constantly:
graph TD
AP[Access Point]
GamingPC[Gaming PC<br/>Strong Signal]
Phone[Phone<br/>Medium Signal]
Camera[Cheap Camera<br/>Weak Signal]
AP --> GamingPC
AP --> Phone
AP --> Camera
The gaming PC may have excellent signal quality and powerful hardware, but the cheap wireless camera behind several walls can still degrade the experience for every other client because it consumes airtime inefficiently.
This is one of the reasons overloaded apartment environments often feel unstable despite modern hardware. The problem is not always bandwidth exhaustion. Sometimes the RF medium itself simply becomes inefficient under contention.
The concept of airtime fairness became increasingly important in modern Wi-Fi deployments precisely because of this behavior.
2.4 GHz Becomes Chaotic Very Quickly
The 2.4 GHz ISM band remains useful because of its range and wall penetration characteristics, but those same characteristics also create many of its problems.
Signals propagate far enough that neighboring apartments frequently interfere with each other. In dense residential buildings this creates situations where dozens of APs end up competing within the same limited channel space.
A simplified version looks something like this:
graph TD
AP1[Apartment A<br/>Channel 1]
AP2[Apartment B<br/>Channel 6]
AP3[Apartment C<br/>Channel 1]
AP4[Apartment D<br/>Channel 11]
AP5[Apartment E<br/>Auto Channel]
Real environments are usually worse than this because:
- many APs use poor defaults
- channel widths become excessive
- mesh repeaters increase contention
- IoT devices continuously chatter in the background
- cheap routers implement questionable RF behavior
This eventually turns into various forms of co-channel interference, especially in apartment buildings where dozens of overlapping networks compete simultaneously.
This is why Wi-Fi performance often changes dramatically depending on the time of day. The RF environment itself changes as neighboring devices become active.
You can actually observe this in apartment buildings by opening a Wi-Fi analyzer during the evening and watching the spectrum become increasingly crowded.
5 GHz And 6 GHz Changed Expectations
Part of the reason modern Wi-Fi improved so much over the last decade was the migration away from overloaded 2.4 GHz environments toward 5 GHz and more recently 6 GHz networks.
The tradeoff is fairly straightforward:
- 2.4 GHz travels farther and penetrates walls better
- 5 GHz and 6 GHz provide cleaner spectrum and higher throughput
- higher frequencies generally suffer more attenuation through walls and distance
This is one of the reasons mesh systems became popular. Many homes now rely on multiple APs because modern high-frequency Wi-Fi performs best with shorter distances and cleaner RF environments.
The problem is that devices often fall back to 2.4 GHz once signal quality becomes poor enough, especially in larger apartments or houses with thick walls.
Something like this becomes very common:
graph LR
AP[5 GHz / 6 GHz AP]
NearClient[Nearby Devices]
FarClient[Distant Device]
Legacy24GHz[Fallback to 2.4 GHz]
AP --> NearClient
AP -. Weak Signal .-> FarClient
FarClient --> Legacy24GHz
This creates situations where close devices perform excellently while distant devices suddenly become unstable or fall back to heavily congested spectrum.
It also explains why people sometimes buy extremely fast Wi-Fi hardware and still end up with frustrating real-world behavior once they move a few rooms away from the AP.
Roaming Behavior Is Surprisingly Inconsistent
One of the strangest parts of modern Wi-Fi is that roaming decisions are often controlled by the client device itself rather than the access point.
This creates situations where phones, laptops or tablets stubbornly remain connected to distant APs despite having much stronger alternatives nearby.
The result is often confusing:
- signal strength still looks acceptable
- bandwidth remains somewhat functional
- latency quietly becomes unstable
- retransmissions increase dramatically
This is especially common in mesh environments.
A client device may remain connected to a weak node simply because the firmware decided the connection is still technically usable. Meanwhile the AP physically closer to the user sits mostly idle while latency and airtime usage continue degrading.
This behavior varies enormously between vendors and client chipsets, which is part of what makes Wi-Fi troubleshooting so frustrating compared to Ethernet.
Wireless Mesh Is Convenient, But It Has Tradeoffs
Wireless mesh systems solved a real problem for many homes: modern high-frequency Wi-Fi performs significantly better at shorter distances, but many houses and apartments still need coverage across multiple rooms and floors.
The problem is that wireless backhaul itself consumes airtime.
In many mesh deployments, the same RF medium is simultaneously carrying:
- client traffic
- AP-to-AP backhaul traffic
- retransmissions
- roaming management
- broadcast traffic
Something conceptually closer to this happens:
graph LR
Internet((Internet)) --> Router[Router]
Router --> MainAP[Primary Mesh Node<br/>wired uplink]
MainAP == "wireless backhaul<br/>shared RF airtime" ==> MeshAP[Secondary Mesh Node]
MeshAP --> Client[Client Device]
Client -. "client traffic also<br/>competes for airtime" .-> MainAP
Under load, this can create situations where:
- latency spikes increase dramatically
- throughput collapses unpredictably
- roaming becomes inconsistent
- retransmissions accumulate quickly
This is one of the reasons wired backhaul often improves mesh stability so dramatically. Once the AP-to-AP communication leaves the wireless medium, the amount of airtime available for client devices increases substantially.
Many people interpret this as:
“wired backhaul makes mesh faster”
but in practice it often makes mesh more stable, which is usually the more important improvement for interactive workloads.
Retransmissions Quietly Destroy Stability
Wi-Fi retransmits packets constantly. This is normal behavior and not necessarily a sign of failure.
Frames get corrupted, acknowledgements disappear and interference changes dynamically. The AP and clients continuously retry transmissions using mechanisms similar to Automatic Repeat Request to maintain reliability.
Conceptually, this happens constantly in the background:
sequenceDiagram
participant Client
participant AP
Client->>AP: Send Frame
AP--xClient: ACK lost
Client->>AP: Retry Frame
AP->>Client: ACK received
The problem is that retransmissions themselves consume airtime. Under load, retries accumulate and begin increasing contention, queueing and latency for every client sharing the medium.
This becomes especially noticeable once homes start simultaneously running video calls, cloud backups, streaming, gaming traffic, VPN overlays, IoT traffic and wireless mesh backhaul.
At that point the AP often spends a surprising amount of time recovering from RF instability instead of efficiently delivering useful traffic.
This is also one of the reasons many people started separating IoT devices into dedicated networks or VLANs. A large number of IoT devices are extremely cheap from a networking perspective. They often have weak radios, poor roaming behavior, aggressive retry patterns and noisy background traffic.
The issue is usually not bandwidth usage. Most IoT devices barely use meaningful throughput. The problem is that they still consume airtime continuously.
Something like this became very common in homelab and enthusiast environments:
graph TD
Router[pfSense / OpenWRT]
Router --> MainWiFi[Main Wi-Fi]
Router --> IoTVLAN[IoT VLAN / SSID]
MainWiFi --> Laptop
MainWiFi --> GamingPC
MainWiFi --> Phone
IoTVLAN --> Camera1[Camera]
IoTVLAN --> Camera2[Cheap Camera]
IoTVLAN --> Plug[Smart Plug]
IoTVLAN --> Alexa[Voice Assistant]
IoTVLAN --> Bulb[Smart Bulb]
The goal here is not only security isolation, although that is part of it. It is also about reducing unnecessary contention and instability on the primary wireless network.
Interestingly, many people initially approach VLANs and IoT segregation thinking mostly about cybersecurity, then eventually discover they accidentally improved network stability too.
Bufferbloat Feels Worse Over Wi-Fi
In the previous article about BBR and bufferbloat, I discussed how oversized queues can silently destroy responsiveness under load even when bandwidth itself is plentiful.
Wi-Fi makes this even more painful because the wireless layer introduces additional instability before traffic even reaches the WAN connection.
Something closer to this starts happening:
graph TD
A[Client Upload]
B[AP Queue]
C[Wi-Fi Contention]
D[Retransmissions]
E[Router Queue]
F[ISP]
G[Internet]
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
Now somebody starts a Steam download, a cloud sync, a backup job or a speedtest, and suddenly latency spikes massively despite the WAN itself still having plenty of available bandwidth.
This is one of the reasons why enabling proper SQM and modern Active Queue Management systems like FQ-CoDel or CAKE on routers running pfSense or OpenWRT often improves the perceived quality of the network more than simply upgrading bandwidth again.
Queue Management Matters More Than People Think
One of the more interesting realizations from the bufferbloat era was that queue management frequently matters more than raw bandwidth once a connection reaches a certain speed.
Without proper queue management, heavy uploads or downloads can silently create extremely large queues inside routers and access points.
Conceptually, something like this happens:
graph TD
A[Heavy Download]
B[Large Router Queue]
C[Massive Latency Spike]
A --> B --> C
With proper SQM and queue management systems like FQ-CoDel, queue growth becomes significantly more controlled:
graph TD
A[Heavy Download]
B[SQM / FQ-CoDel]
C[Controlled Queue]
D[Stable Latency]
A --> B --> C --> D
This is one of those networking concepts that sounds minor until you experience it directly. A connection with slightly lower throughput but stable latency under load usually feels dramatically better than a faster connection with uncontrolled queue growth.
The DIY Router Era Happened For A Reason
One of the more interesting developments in home networking over the last decade was the rise of DIY routing and enthusiast firewall platforms.
A large number of users eventually realized that consumer ISP routers were not handling modern workloads particularly well. Homes gradually evolved from a few phones and laptops into environments simultaneously running remote work, VPN overlays, cloud synchronization, cameras, streaming platforms, gaming workloads and increasingly large numbers of IoT devices.
Consumer routers often struggled under this level of concurrency, especially once latency-sensitive workloads became more common.
The rise of cheap x86 mini-PCs accelerated this movement considerably. Suddenly it became possible to build extremely capable routers using low-power hardware that could comfortably run advanced queue management, WireGuard tunnels, multi-WAN failover and complex firewall rules without struggling under load.
This is part of the reason projects like pfSense, OpenWRT and OPNsense became so popular among enthusiasts and homelab users.
People started discovering that reducing latency under load frequently improved the user experience more than increasing raw throughput.
That realization became increasingly mainstream over time, especially after creators began publishing detailed videos replacing consumer routers with pfSense appliances, OpenWRT systems and x86 mini-PC routers.
The popularity of these videos came from a very real frustration people were already experiencing with overloaded consumer hardware and unstable wireless environments. It was not only about wanting a more advanced dashboard. It was about getting visibility into the parts of the network that actually affect responsiveness.
Things That Usually Help
Most Wi-Fi problems are not solved by buying the most expensive router available. Stability improvements usually come from reducing contention and improving RF conditions rather than maximizing theoretical throughput.
A few things that consistently help:
- prefer wired backhaul for mesh systems whenever possible
- use 5 GHz or 6 GHz for latency-sensitive devices
- avoid placing APs near TVs, metal surfaces or inside furniture
- reduce oversized channel widths in crowded apartment environments
- separate noisy IoT devices into dedicated VLANs or SSIDs
- use SQM or FQ-CoDel on WAN links to control queue growth under load
- prefer multiple properly placed APs over one extremely powerful AP
- avoid cheap wireless repeaters whenever possible
- test roaming behavior instead of assuming mesh systems handle it correctly
- periodically inspect channel congestion using Wi-Fi analyzer tools
Most importantly, treat Wi-Fi as a shared RF environment instead of invisible Ethernet.
A large percentage of what people describe as “bad internet” is often just local contention and airtime problems hiding behind otherwise healthy WAN connectivity.
Wi-Fi Is Still An Incredible Engineering Achievement
Despite all the complaining in this article, Wi-Fi is still remarkable technology.
Modern wireless networks allow dozens of devices to communicate simultaneously through walls, across multiple rooms and under constantly changing RF conditions while maintaining throughput levels that would have looked absurd not very long ago.
The problem is mostly expectations.
People started treating Wi-Fi as invisible Ethernet, when in reality it is a constantly changing shared RF environment trying to coordinate many devices with very different signal conditions and behaviors.
Once you start observing airtime contention, retransmissions, roaming behavior and queue growth directly, Wi-Fi problems stop feeling random.
A lot of what people describe as “bad internet” is often just a heavily contended wireless environment behaving exactly the way shared RF networks tend to behave under load.