[tcpm] Possible deadlock scenario with retransmission on both sides at the same time

[Kobby Carmona <[e-mail]>]

Hi all,
While running a bidirectional scenario with random drops in a network simulator of our (QLogic's NIC) TCP stack we found a case where it seems there is deadlock in the TCP protocol (the connection will keep sending pure acks from both sides until RTO will expire multiple times and a RST will sent to close the connection).
The scenario is as follows (there is an example with numbers for each stage assuming the MSS and each packet is 1000B):
1. Both sides are transmitting data and a single packet is dropped on either side and the next two packets are received properly
	Side A - SND.MAX=3000, SND.NXT=3000, SND.UNA=1000, RCV.NXT=11000, out-of-order block 12000-13000
	Side B - SND.MAX =13000, SND.NXT =13000, SND.UNA=11000, RCV.NXT=1000, out-of-order block 2000-3000
2. RTO timer expires on both sides
	Side A - SND.MAX=3000, SND.NXT=1000, SND.UNA=1000, RCV.NXT=11000, out-of-order block 12000-13000
	Side B - SND.MAX =13000, SND.NXT=11000, SND.UNA=11000, RCV.NXT=1000, out-of-order block 2000-3000
3. Both sides transmit a single packet to the peer:
	A->B - pkt.seq=1000, pkt.ack=11000, len=1000
	B->A - pkt.seq=11000, pkt.ack=1000, len=1000
3. Both sides receive the packets and update the receive context:
	Side A - SND.MAX=3000, SND.NXT=2000, SND.UNA=1000, RCV.NXT=13000
	Side B - SND.MAX=13000, SND.NXT=12000, SND.UNA=11000, RCV.NXT=3000
4. Both sides send another segment:
	A->B - pkt.seq=2000, pkt.ack=13000, len=1000
	B->A - pkt.seq=12000, pkt.ack=3000, len=1000
5. Both sides don't accept the packet (and don't update SND.UNA) since the sequence on the packet is less than RCV.NXT (sequence number check in page 69 of RFC793) and send a pure ACK instead
	A->B - pkt.seq=2000, pkt.ack=13000, len=0 (pure ACK)
	B->A - pkt.seq=12000, pkt.ack=3000, len=0 (pure ACK)
6. This will continue forever (until the connection will be terminated by RST) since every packet that ends before RCV.NXT (even a retransmit from SND.UNA) will be dropped.

Did anyone encountered this issue before? Is the anything we missed on this sequence?
If this is indeed a real deadlock, there might be several solutions to this which will require a modification in receive processing of RFC793. But I would like to know if you think this is a real issue before dealing with solutions.
Thanks,

	Kobby