Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!AMES-NAS.ARPA!rfox From: rfox@AMES-NAS.ARPA (Richard Fox) Newsgroups: comp.protocols.tcp-ip Subject: Re: Acking out-of-order packets? Message-ID: <8803032139.AA11230@ames-nas.arpa> Date: 3 Mar 88 21:39:25 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 88 >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