Phil,
At 04:01 PM 1/21/99 , Phil Karn wrote:
>>-> 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.
Sure, timestamps work as a first approach but don't you think that we can
get away with far less overhead (my proposed 2 bits). The problem with
timestamps is that they are 12 bytes TCP options which usually can't be
compressed. Aren't there any available bits left over in the standard TCP
header? I don't want to dare to propose any ;-) With 2 bits we could
unambiguously mark the first 7 transmissions of a packet. If things have
gotten so far, spurious timeouts are the least thing we have to worry about.
>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.
I'm working on that as I write. My hope is to get it ready by the end of
this month but let's see ...
>>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.
In turns out that the biggest variation on low bandwidth links where the
RTT is dominated by the packet transmission delay is what we call "TCP's
homemade variation". That is, whenever the sender grows it's congestion
window by 1 during congestion avoidance and the pipe is full the packet
goes into the queue and consequently increases the RTT. The RTO fires up in
a response to that. Before the RTO converges back, the next additional
packet goes into the queue firing up the RTO yet again, and so forth. The
biggest difference between RTO and RTT is seen when the queue eventually
drops a packet triggering fast retransmit, the sender responds by not
sending anything for roughly 1/2 of the latest RTT, and thus the queue
drains. The next measured RTT will be fairly low again but the variation
(which is always a positive value in the RTO calculation) huge. The RLP
sender could go for a cup of coffee during that time, come back and still
things would be fine.
>>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.
What should actually be done is that whenever the Rexmt timer gets
re-started with the RTO the "age" of the oldest byte should be substracted.
That would certainly make the slack for the fast retransmit algorithm very
slim but the conservativeness should be designed into the RTO and not into
the way the Rexmt timer is started.
>>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.
Are you saying that you don't have a problem with VJ header compression
over CDMA? When the IS95-RLP tosses a frame and the PPP receiver discards
the entire packet you must have that problem unless other precautions have
been put in place. Certainly header compression is important as it
increases throughput by roughly 14 percent when running the usual PPP MTU
of 296 bytes.
>>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.
Shouldn't we much rather promote the use of the ECN scheme instead?
>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.
Right, that's why ISP's should (and some do) configure their dial-up lines
to not allocate more than 3-4 packets per modem. For the same reason
wireless hosts which usually don't have to many flows active and sending at
the same time should also not have a much bigger interface buffer.
>How often does it
>really happen, and what effect does it have on throughput? I want
>numbers...
The theory goes like this: if you allow a buffer equal or greater than the
pipe capacity (note that this is not the bandwidth x delay product as
probed out by TCP because that will always include the unknown amount of
buffer capacity at the bottleneck link) then TCP will fully utilize the
link. This is true as long as only one packet per congestion avoidance
cycle is lost. If you don't have multiple congested links in the path the
latter assumption is actually not so unrealistic. You don't want to buffer
much more then the pipe capacity otherwise the windows and the RTT inflate.
Thus, if you really want to use that rule you need the available bandwidth
at the link if that is known (easy for non-shared dial-up connections) and
you have to guess some fixed RTT (e.g. 2-3 seconds).
>>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, [...]
Sure, that's what we are doing right now but we think that it is a bit of
an overkill. We would prefer having only 2 bits.
>>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.
That's how it also works in GSM. So you must also see the problems with VJ
header compression in IS-95. Is there a user configurable parameter to
change the max. number of retransmissions for the IS95-RLP like in GSM? An
AT command for example?
///Reiner
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST