Iljitsch van Beijnum <iljitsch@xxxxxxxxx> 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