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
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. End-to-end retransmits take even longer because of speed
of light delays.,
That is a improper calculation.
The requirement from TCP is that, on lightly loaded link,
probability of packet drop should be very small.
For example, if probability of collision is (despite CSMA/CA) 0.1,
2 retries will be enough to make packet drop probability 0.1%.
If there are hidden terminals, probability of interference will
get worse that more retry will be desired.
And, with exponential back-off, delay will be doubled as the
number of retries in increased by 1.
Coupled with aggressive FEC, that's more than enough time.
FEC sucks because it also eats away at usable bandwidth when there are
FEC is fine against thermal noise.
However, FEC does not work at all here, because, with a collision,
contents of colliding packets will be lost almost entirely.
1. Make sure access points don't have to contend with each other for
airtime on the same channel
2. Make sure access points transmit with enough power to be heard over
clients associated with other access points
3. Refrain from using too much bandwidth
4. Make use of higher-bandwidth wireless standards such as 802.11g
2 should be:
Make sure clients and access points transmit with equal power
to be heard over each other to enable CSMA/CA collision
avoidance with random delay
1 is a performance improvement but is not a serious problem if
CSMA/CA is working well.
3 is not specific to wireless and is irrelevant.
4 helps little but is not very meaningful as PPS, rather than BPS,
is becoming the limiting factor, especially for applications with
small packets such as VOIP.
By the way, it would also be a good idea if the standard did proper
power control of the mobile stations.
Why? Raising the power output of the stuff you want to hear over these
clients is much, much simpler.
It is a good idea for some wireless protocol.
However, it is the worst thing to do against CSMA/CA.
Others won't notice your presence and won't reduce transmission rate.
By the way, I did some testing today and the results both agree with and
contradict conventional wisdom with regard to 802.11 channel
utilization. When two sets of systems communicating over 802.11b/g are
close together, they'll start interfering when the channels are 3 apart
(ie, 5 and 8), slowing down data transfer significantly. This indicates
that in the US only three channels can be used close together, but four
in Europe: 1, 5, 9, 13. However, with the two sets of stations are NOT
close together (but still well within range), such as with a wall in
between them, 3 channels apart doesn't lead to statistically significant
slowdowns, and even 2 channels apart is doable: 25% slowdown at 802.11b
and 50% slowdown at 802.11g. So that would easily give us four usable
channels in the US (1, 4, 8, 11) and 5 in Europe (1, 4, 7, 10, 13), or
even six / seven (all odd channels) in a pinch. (As always, your milage
may vary. These results were obtained with spare hardware lying around
The results, it seems to me, completely agree with the conventional