Hi Venkat,
I was waiting for you ...
At 02:40 PM 1/21/99 , Venkat Padmanabhan wrote:
>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.
I fully agree in so far that when things on a link (especially the
bottleneck link) change considerably (e.g. route change, temporary outage
or cell handover and now the bottleneck wireless link has considerably less
bandwidth) then you want the sender to "reset" and (slow-)start to probe
for the new characteristics of the path. It then does not make sense to
fool the sender into believing that things are fine if they are not.
> If a mobile receiver enters and stays in
>an area of poor coverage for a considerable length of time,
This would also be such an example.
> there
>may not be much point in retransmitting a data frame indefinitely
>(or even a large number of times) at the link layer.
Certainly there will be some link termination timer implemented at the link
layer a la "disconnect if outage > treshold time". This is exactly what
e.g. GPRS does.
> [...] it would at least
>free up transmission slots at the base station for communication with
>better-placed receivers.
I don't quite get this. In a well designed system you have a MAC protocol
that schedules among each link layer sender's queue. If the wireless
network operator paid a lot of money for the wireless spectrum (like all
the PCS operators did) then this MAC is usually (it better is) under
central control of the network, i.e. the "right to send" is assigned by the
network and usually that is also the basis for charging. That might be
different in 802.11 WLAN operating in licence-free spectrum but I don't
really know how the 802.11 works.
>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.
That works if you still have the time to send the signal that forces the
sender into persist mode but I agree given that you have the chance to do
so that's a nice 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.
GSM has "build in" frequency hopping, adaptive power control, FEC, and
interleaving but there is no direct tie-in of these with the link-level
retransmission scheme. As long as the constantly measured radio link
quality is above treshold the link-level sender does it's job. Otherwise
it's told to give up because the link is considered to be broken
///Reiner
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST