Iljitsch van Beijnum <iljitsch@xxxxxxxxx> writes: > On 19-nov-03, at 23:16, Perry E.Metzger wrote: > >>> I think there is some middle ground between 25000 and 10 ms. > >> 10ms is the middle ground. That's enough for a bunch of retransmits on >> modern hardware. > > Retransmits on what type of hardware? At 1 Mbps transmitting a 1500 > byte packet already takes 12 ms, without any link layer overhead, > acks/naks or retransmits. Most of us are not running at that speed on 802.11b. Obviously if you're running at a lower speed adjustments should be made. > End-to-end retransmits take even longer because of speed of light delays., We're talking about to the base stations only. End to end is not the issue. The issue is 802.11 tries to be reliable to the base station, with disastrous results. >> Coupled with aggressive FEC, that's more than enough time. > > FEC sucks because it also eats away at usable bandwidth when there > are no errors. Having TCP collapse sucks too, because then no one can use the network. In any case, one can adjust the the armor to cope with the average bullet density. If the S/N is clean, you don't need as much FEC. >> If the network is so loaded that you can't send a packet in that >> period, you should drop so that all the TCPs back off. > > Absolutely not. Well, then, I'm sorry that you don't understand what happens to TCP under these circumstances, but some of the rest of us do. I was seeing packet traces showing clear signs of congestive collapse on the radio networks, and most of it was created by the packet warehousing our lovely 802.11 hardware believes it should do to "help" with the packet loss problems. It all reminded me horribly of the sorts of packet traces one saw on ARPANET and NYSERNET before VJ flow control became the norm. I really regret not saving packet traces. If I had known some people didn't understand congestion control I wouldn't thrown them away. Luckily, there is always the next conference. Perry