[derefr]

I say "disconnect" but I don't mean that the 802.11 PHY driver of the computer or the base station notices that there's a disconnection. Just that there's a time-correlated burst of packet loss on some/all channels.

This might not ever happen to you if you live in a bunker, or on a farmstead at least 500 feet from any neighbours. (Though I wouldn't completely discount the possibility; there's always solar storms.)

But if you live in a city, and like to sit near large picture windows (where the light from the window cuts across the straight-line path between your wireless devices and their base station), then every once in a while you're going to get what's basically a mini-EMP blast blowing through your window glass, on one random unlicensed-spectrum-interfering frequency on another: every time someone in the building across from yours vacuums with a 1950s vacuum cleaner with an ungrounded plug, or uses their shitty $50 freestanding microwave with underspecced side shielding; or operates their unlicensed AliExpress garage-door opener, or... etc.

If we could hear 2.4/5GHz, every day in a city would sound like Diwali: sudden short explosions, from every direction, at any odd hour of the day.

Remember, "unlicensed" spectrum means the FCC isn't policing those bands like they do with licensed allocations; so all the 2.4/5GHz "polluters" — the device buyers, and the manufacturers — never get told to stop.

[havkd]

A burst of packet loss that doesn’t translate into at least a disconnection of current TCP streams is, by definition, not a disconnection.

[derefr]

There are plenty of connection-oriented protocols other than TCP that do experience a disconnect during these packet-loss bursts. RTP, for example.

There's a reason IP softphones are always wired, rather than being wi-fi devices — speaking RTP, they can't tolerate the somewhat-normal condition of RF-interference-induced 802.11-PHY packet-loss bursts nearly as well as devices speaking TCP can. They end up dropping calls in about the same way that Bluetooth Audio drops pairing.

(This is also most of why 802.11e QoS Traffic Categories exist — RTP is essentially hard-realtime, so even temporarily queuing RTP packets due to competing high-throughput TCP flows, could be enough to "choke out" the RTP flow.)

[havkd]

That seems a problem with RTP more than with wireless connections.

[Majromax]

No, it's an inherent problem whenever a packet-switched, multi-user, shared channel inherently built around queued transmission tries to emulate real-time protocols, the earliest of which is "a directly-connected wire."

This sort of substitution can work, but it requires very stable, low-noise links (that is, with little to no burst noise) and the cooperation of devices and network equipment.

[NobodyNada]

...Okay, how would you suggest a better protocol avoid that problem? For voice/video calls, you need a fairly small buffer size so that latency isn’t distracting. But if you have a (say) 250ms buffer, and the wireless connection drops out for 500ms, then there’s no way to avoid losing some packets.

TCP’s reliability comes at the cost of increased, inconsistent, and unpredictable latency; which is fine for downloading a file, browsing the web, or streaming video with a 30-second buffer; but unacceptable for a real-time call.