>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
Be careful, lest you reinvent TP4. It had a field for this specific
purpose, though I don't remember the name and size offhand.
>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
Yup, there are 6 reserved bits. One is needed to echo the Explicit
Congestion Notification bit back to the sender, and you don't want to use
more than half of the remaining bits so you can have a field for each
direction. That gives you 2 bits each way -- what a coincidence!
>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
That's as good a term for it as any. I still think ICMP Source Quench
is a good approach to the problem, but perhaps ECN will work just as
well. There's no real reason to keep more than one packet on the queue
of a bottleneck link, and it's hard for TCP to know without being
told.
>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.
Isn't this similar to the old practice of having a separate RTO timer
for each segment? If so, I think there are some studies that may be
helpful.
>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
RLP almost always recovers in one or two retransmissions, so even
though it isn't absolutely reliable, a packet loss is still a very
rare event. So it just doesn't matter much what happens when it does
lose.
To illustrate, here are some numbers:
Usable frame payload: 20 bytes (8 Kb/s channel) 32 bytes (14kb/s channel)
Frame rate: 50Hz (20 ms)
Typical frame erasure rate (FER): 1-2% (max)
>From here I'll use the 14kb/s numbers, as that's the more widely
deployed version (e.g., Sprint PCS).
>From these numbers you can see that the probability of a 576 byte
packet making it through without a retransmission is
576/32 = 18 frames (ignoring PPP framing & byte stuffing)
(1-.01) ** 18 = .8345.
(1-.02) ** 18 = .6951
I.e., assuming independent losses, and without ARQ in the RLP, the
packet loss rate would be 16.5% for a 1% channel FER and 30.5% for a
2% channel FER. This clearly demonstrates the value of link level ARQ.
Now let's allow just 1 retransmission (max) for each frame. The
probability of a frame getting through when the FER is 1% is now
1-(.01)**2 = .9999 and the probability of the whole 18-frame packet
getting through is 99.8%. Much better! Increase the maximum number of
frame retransmissions to (3=1+2) and the number goes to 99.999982%. Even
for FER=2%, the success rate is still 99.9997%. Few Internet paths are
this good, which is why there's little reason to make it any better.
True, the losses aren't independent, so these figures are a little
optimistic. But no amount of retransmitting will help if you've gone
into a tunnel or otherwise out of range, so the analysis is still
indicative of how a little link-level ARQ goes a long way.
Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST