Perry;
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