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