>Here's a thought. Ever since "TCP over wireless" became a popular
>topic for research, the conventional wisdom has been that TCP-style
>congestion control is the wrong response to wireless errors. This
>may not be entirely true. If a mobile receiver enters and stays in
I agree, and I frequently make the same point. The signal-to-noise
ratio on a CDMA channel is dominated by interference from other
users. (It's actually a signal-to-interference ratio, but the
interference looks like noise). So in CDMA, many/most packet losses
are actually caused by congestion -- just as they are in a conventional
shared point-to-point link!
Congestion still has to be handled by the transport protocol, but
channel noise is best handled by FEC at the physical layer, perhaps in
combination with ARQ. I really don't think channel noise should be a
concern of TCP.
>Of course, it would be desirable to have the TCP sender quickly
>ramp up when the link quality improves. Schemes such as the one
>proposed by Brown and Singh (CCR, Oct 1997) might do the trick.
I proposed an "ICMP destination reachable" message many years ago. Is
this like that?
>mechanisms. I know that in some frequency-hopped systems, a
>retransmission is done only after the channel has switched to a
>different frequency in the hope that this would improve the chances
>of success.
There are two kinds of frequency hopped systems, slow and fast. I
think even the slow systems typically hop at least once per packet,
which means retransmissions will occur after a hop.
If you hop faster than a packet time, erasure-correcting FEC is a good
way to deal with hops that land on narrowband interference.
Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST