Iljitsch van Beijnum <iljitsch(_at_)muada(_dot_)com> writes:
On 18-nov-03, at 15:56, Perry E.Metzger wrote:
The fact that 802.11 tries to be
reliable by doing its own retransmits results in massive congestive
collapse when a protocol like TCP is run over it.
Hardly. TCP plays nice and slows down when either the RTTs go up or
there is packet loss (which will happen due to congestion
eventually).
I would suggest that you have a look at what tcpdump looks like in a
conference room at the IETF. It isn't pretty. I'm kicking myself for
not saving my packet traces -- they would make my point far better for
me than any amount of argumentation in English.
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.
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.
Perry