Radio links like this are simply too unreliable to run without additional protection: TCP isn't equipped to operate in environments with double digit packet loss percentages.
I agree with you, Iljitsch.
A protocol that had been tuned for use with TCP would have been fine -- heavy FEC and some moderate retransmissions in case of corruption or station handoffs are okay. The problem is not when you try to be reliable in the face of radio interference, but when you also try to be reliable in the face of congestion -- which is precisely what the system does. Storing huge queues of packets when there is congestion does no one any favors. TCP needs packet drops and fairly low standard deviations on packet delays to do its job well, and 802.11 does precisely the wrong thing.
But, Ethernet does (or did, when it was CSMA) the same thing and RFC1958 says:
To quote from [Saltzer], "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.")
Because of exponential backoff, aggregated bandwidth of multiple TCP over congested WLAN should not be so bad.
However, RED like approach to attempt retries only a few times may be a good strategy to improve latency.
Masataka Ohta