Message-Id: <199902030027.QAA06775@owl.ee.lbl.gov> To: end2end-interest@ISI.EDU Subject: Re: TCP and out-of-order delivery Date: Tue, 02 Feb 1999 16:27:35 PST From: Sally Floyd This is background for a thread that started out on the pilc mailing list, and that now is migrating to end2end-interest instead. Followup should be on end2end-interest, I would say. - Sally ------- Forwarded Message Date: Tue, 02 Feb 1999 11:27:28 -0800 From: Sally Floyd To: karn@qualcomm.com cc: pilc@lerc.nasa.gov, Tom Henderson Subject: Re: TCP and out-of-order delivery Phil - >The fast recovery mechanism in TCP has always bothered me a little >precisely because its reaction to out-of-order delivery. The Internet >architecture has always permitted this, even if it doesn't happen all >that often in practice (yet). Even without radio links, the increased >use of load splitting will make this a problem worth solving at the >TCP level. My understanding is that the TCP-level solution to TCP's problems with out-of-order delivery would go as follows: (1) Add a recommendation to SACK so that, when the receiver receives a packet that is already covered by the cumulative acknowledgement, the receiver not only returns a dup ack (as it does now), but uses the first SACK block to indicate the sequence numbers of the packet that resulted in the dup ack. If the receiver also holds some non-contiguous blocks of data, they could be reported in the second and third SACK blocks. With this added recommendation (which would be optional, but which does not violate anything in the SACK RFC 2018, I believe), the sender would be able to reconstruct the exact sequence of data received by the receiver. (2) Consider a case where the sender receives three dup acks, infers that packet N has been lost, enters Fast Recovery, and retransmits packet N. If packet N in fact was not lost, but was simply reordered, then the sender will be able to detect this later on (assuming that acknowledgements aren't lost on the return path). Thus the sender can determine that it did not need to retransmit packet N, and it did not need to reduce its window in half. If the sender determines after-the-fact that it did not need to retransmit packet N, there is not much that it can do about it, except perhaps to modify its dup ack threshold. The bandwidth wasted by the unnecessary retransmission of that packet has already been wasted. But the sender can do something when it determines that it unnecessarily reduced its congestion window. That is, the sender can put ssthresh back to its old value (before it cut ssthresh in half when it initiated Fast Recovery), and safely slow-start back up to its old congestion window. I think that this would be a simple and clean change to make to SACK TCP, and would take care of some of the performance problems of TCP with load splitting and other forms of strong out-of-order delivery. (Though of couse it would need some exploration first.) (There are also not necessarily original ideas, though I don't know off-hand of any citations. I have talked with a number of people about this since the SACK RFC was first started, most recently with Tom Henderson, who pointed out to me the problem with this proposal in the absence of (1) above.) - Sally ------- End of Forwarded Message