Reiner,
Thanks for your most interesting note!
>-> To be fair I have to say that we were using TCP-Timestamps to get more
>instant feedback when the RTT increased if e.g. the link quality started to
>decrease and RLP had to do more retransmissions. So probably timing every
This is an interesting topic for this group. The usual instinct is to
minimize headers when operating on a slow (e.g., wireless) channel,
but sometimes a little extra overhead might actually improve
performance. You don't have to avoid very many TCP data packet
retransmissions to repay the cost of the TCP header timestamps.
I've always considered my own algorithm for handling ack ambiguity to
be a bit of a hack, and header timestamps are a much cleaner
solution. So some simulations and/or measurements of the effect of the
TCP header timestamp option on wireless throughput would be helpful
here. If the results are consistent, we should mention them in
whatever recommendations we produce.
>A. the hyper-senstivity of the RTO to RTT variations and B. the fact that
Right. Even on an unloaded LAN path, the usual disk I/O and OS
scheduling latencies typically causes a fair bit of variance in the
sender's RTT measurements.
>TCP's Rexmt timer is always off by roughly one RTT because (at least in
>BSD-derived implementations) the Rexmt timer gets re-started
>(re-initialized with the RTO) with every ACK for new data. You do need some
This seems to be a widespread practice. I know I did it in my own TCP,
on the theory that retransmissions should be avoided as long as the
transfer is making progress.
>2. Semi-reliable ARQ as you proposed can do a lot of harm when you are
>running VJ TCP/IP header compression which you certainly want to do on a
>low bandwidth link. The reason is that the header decompressor screws up
>when one or more packets are lost causing checksum errors at the TCP
>receiver and thus a loss of an entire window. This is particularly painful
I was also concerned about this issue, but it turned out not to be a
problem with CDMA. I originally allowed three link-level
retransmission cycles, sending the third retransmission three
times. We changed the standard to allow only two retransmission
attempts because we found that the protocol very rarely got to the
third on a channel that hadn't already failed completely anyway, e.g.,
because the user drove into a tunnel and the call dropped. And there
were concerns about the required buffer space at the sender. RAM is
very much at a premium in a portable cell phone, where the RLP is
implemented.
>receiver and thus a loss of an entire window. This is particularly painful
>when you are running over a massively overbuffered link because the windows
>grow huge. The latter happens easily: just take a BSD-UNIX machine which by
Right, a classic problem on dialup links. Both there and on CDMA I
experimented with ICMP Source Quench messages to keep the link queue
from getting too deep. I was mainly concerned about the latency
encountered by an interactive session sharing the link with a bulk
transfer, though of course TOS queuing is the better approach. In any
event, ICMP SQ messages worked very well at keeping the queues from
getting too big with no deleterious effect on throughput. I've never
accepted the conventional wisdom that SQ is bad.
I should point out that your window won't have a chance to grow huge
in the first place if the link regularly loses packets. In other
words, the VJ 'pipe flush' problem is self-limiting. How often does it
really happen, and what effect does it have on throughput? I want
numbers...
>are currently implementing a "spurious timeout detection mechanism" . The
Can you use header timestamps as a clue here? The time field can serve
as a transmission serial number, and since these are echoed in the
echo reply field the sender can tell how many copies of the same data
got through.
>Not necessarily. Would be interesting to see measurements with the IS95-RLP
>when you do more retransmission attempts than just 2.
As mentioned earlier, our tests in the lab and on the road showed that
it was extremely rare to reach the third retransmission cycle, except
when the channel was unusable anyway. When the call drops (this being
a connection-oriented physical link), the send queue is
discarded. Each subsequent TCP retransmission triggers another call
attempt, and since the retransmissions are backed off exponentially, so
are the call attempts. Eventually the RF path returns and the call attempt
succeeds on the next TCP retransmission.
>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.
The link RTT is measured at call setup and is used to time the
retransmission requests. The RTT is dominated by system delays; the RF
propagation delay is minimal by comparison so the variance is
small. This has the effect of limiting the max time spent
retransmitting a frame.
>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?
The latter. It simply delivers the frame to PPP with a piece missing.
The PPP CRC fails and drops the whole frome. The layering is cleaner
this way. The RLP works on a featureless byte stream just as a dialup
modem does. It knows nothing of PPP frames or IP datagrams.
>Good point. The GSM designers certainly overdid it when they designed the
>interleaving scheme for GSM CSD introducing a one-way (!) latency of
>roughly 100ms (!). Fortunately, this has been corrected for the upcoming
>GSM packet data service.
Interleaving in a packet service is best performed over the entire
packet. You have to wait for the whole packet anyway, so it doesn't
cost extra. Unfortunately IS-95 was originally developed specifically
for voice with a fixed 20 ms frame time, so there's not as much
interleaving as there could have been for larger packets. This is
different in HDR, which is a CDMA-based service we're designing
specifically for packet data.
Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST