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
an area of poor coverage for a considerable length of time, there
may not be much point in retransmitting a data frame indefinitely
(or even a large number of times) at the link layer. We may be better
off by just letting the TCP sender back off. While this would do
little/nothing to alleviate the root cause of errors, it would at least
free up transmission slots at the base station for communication with
better-placed receivers.
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.
A separate question I have in the context of GSM is whether there is
any tie-in between link-level retransmissions and physical-layer
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.
Venkat Padmanabhan
Microsoft Research
padmanab@microsoft.com
http://www.research.microsoft.com/~padmanab
> > I designed the radio link protocol for IS-95 CDMA packet data with
> > this issue specifically in mind. Some form of link-level ARQ is
> > essential in that system, because the raw physical layer
> frame erasure
> > rate (1-2% for a ~30 byte frame) is too high for end-to-end TCP
> > retransmission alone to give acceptable performance. But "too much"
> > link-level ARQ would cause the problem you describe.
>
> Not necessarily. Would be interesting to see measurements
> with the IS95-RLP
> when you do more retransmission attempts than just 2.
>
> > My approach was to limit the number of frame-level retransmission
> > cycles to two, and to send two duplicate copies on the
> second cycle to
> > increase the chances of at least one getting through. This
> design was
> > somewhat ad-hoc, but they seemed to work well in field
> tests. Even a
> > single retransmission made such a dramatic improvement in TCP-level
> > throughput that it didn't matter much what we did beyond that. We
> > simply made the link "good enough" to carry TCP with reasonable
> > throughput. The link didn't have to be, nor should it have been,
> > perfect.
>
> I don't know exactly how the IS95-RLP really works but I
> think it would be
> better to give up on the basis of some treshold retransmission delay
> introduced per packet.
> Something I always wanted to know: Does the IS95-RLP toss the
> entire IP
> packet or only that fragment of it to leave the job of
> discarding to e.g. a
> PPP receiver?
>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST