TCP SACK issue
With TCP SACK, transmission can stall.
[Thomas Reschka:] Martin noticed a bug in TCP SACK and informed Michael about his observation. To reproduce and see the failure please use the following configuration in INET's tcpsack example.
[Config Problem]
description = "Problem Statement"
**.client.pcapRecorder[0].pcapFile = "Problem_Statement_Client_Log.pcap"
**.server.pcapRecorder[0].pcapFile = "Problem_Statement_Server_Log.pcap"
**.tcp.mss = 1000
**.ppp[*].queue.frameCapacity = 20
At event #3218 the client receives a D-SACK with ACK=86001 from the server. Hereafter the client retransmits the segment [86001..87001].
At event #3308 the client receives the 3. DUPACK with ACK=86001 from the server. In the current INET code the client retransmits the segment [86001..87001] again, although already done at event #3308. This seems to be incorrect, because a timeout did not accour at this point and segment [86001..87001] has recently been retransmitted.
I used omnet++ 4.6 and INET 2.99.0.
Issue migrated from http://dev.omnetpp.org/bugs/view.php?id=803