Re: Acking out-of-order packets?


Richard Fox (rfox@ames-nas.arpa)
Thu, 3 Mar 88 13:39:25 PST


>During conversations with Van Jacobsen here at the IETF meeting, I discovered
>an abiguity in the TCP spec (RFC-793 at least), to wit:
>
>What response (if any) should you make when you receive an out-of-order
>segment? RFC-793 says pretty clearly that you should return an empty ACK
>(indicating the sequence number you expect to receive next) if the packet
>is "unacceptable" (i.e., not in the window) but it doesn't say whether
>you should respond if the packet is in the window but not the next one
>expected. It says only that they should be kept for future processing.
>
>My TCP in fact makes no response to an out-of-order data segment. Others
>apparently respond with "do-nothing" ACKs. One of Van's performance tricks
>depends on that behavior. Any guidance on what is the Right Thing here?

Getting a packet out-of-order can mean 1 of 2 things:
        1. Preceding packets were dropped or corrupted and dropped.
        2. The preceding packets are taking a different path than the one
                just received.

In case 1, responding with a "do-nothing" ACK, would get the original
sender to resend the packets before the timeout period elapses. In the case
of a high delay large bandwidth link this is very advantageous to do. Our
TCP will keep out-of-sequence packets on a queue and try to reassemble packets
as they come in until we are caught up. This is a win situation if you delay
your acks. If you immediately send a "do-nothing" ACK the sender will resend
whats already been sent again. Since the packets need to be resent anyways,
being that they will never make it, sending a "do-nothing" packet seems to
be a winner. Also, we might assume that the packet was lost/dropped
because of congestion ( since less than 1% of dropped packets is due to
corruption due to link errors) and then this would set the congestion
control algos. into action much quicker. Thus, congestion can be stopped
much quicker!

As an aside:
So the question at this point is do
we really want to keep the extra complexity of doing reassembling of packets
in the TCP layer as well as the IP?

In case 2, responding with a "do-nothing" ACK would, like in case 1, get the
sender to resend the packets before the timeout period elapses. But since
the packets are going to make it, just a little later than the out-of-seq
packet, this would cause excess packets to be sent over the net. If we
assume that the packets took different paths because of congestion on
a particular link, this could potentially aggravate the congestion problem.
Of course, Van;s algorithm will back off a bit to control the congestion.
Ultimately this could mean that the receiver would tell the sender to re-xmit
all of the packets again, the sender will assume that the network is
congested and should use caution in resending the packets, the receiver
receives all of the packets before the sender has time to re-xmit them all.
The receiver then sends an ACK for all of the data and the sender will not
have to re-xmit all of the packets and can go on transferring new data
by opening back up its congestion window.

I think in case 2 this will work if the assumption that the packets took
different routes because of congestion, with the use of Van's algo. If
a gateway puts packets on different links for the purpose of load
balancing and congestion avoidance then the scenario above for case 2
would break down and the best solution would be to delay any acking for
a period to see if the data is still yet to come. W might still want to
wait for a small period, being that the period be less than the normal
timeout periods currently used.

I am not convinced that load balancing is a good idea, thus, would like to
be able to assume that the only time a packet would travel on a different
route than the previous packet is due to congestion. Then I think
immediately sending a "do-nothing" ACK would be feasible even for
out-of-seq packets that are in the window.

>Perhaps others will either remember differently or have a better
>notion for how to behave under the circumstances described.
>Obviously, if TCP had "out of order" acking and selective
>retransmission, the response would be more complex.
>
>Vint

Up above I have stated that sending a "do-nothing" ACK immediately is
probably the correct thing to do because to try and do anything else would
require more complexity, complexity that TCP was not intended to handle.
If we want the extra complexity, this would mean moving towards a transport
level protocol like VTMP or something like a NETBLT type protocol, which
is quite different than TCP. In the future I think we will need to move
in the direction of a VTMP like protocol so would like to keep it out of
TCP.

Rich



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:30 GMT