Bugzilla – Bug 1227
Spurious RTO due to low min RTO
Last modified: 2011-12-10 21:31:29 EST
Its observed on executing "fifth.cc" the number of RTOs equals the number of RxDrops (11) This can be found using the logging "export NS_LOG=TcpL4Protocol:TcpNewReno" This use-case has two cases of RTOs 1. After TCP exits fast-recovery, the Cwnd permits only 3 packets as in the case of seq # 54617.Further, TCP remains in Conge stion-avoidance & thus will grow the CWnd per RTT. So with Cwnd==3 TCP sends the following seq # 54617,55121,55657. #54617 is dropped and the sender receives only 2 ACKs for # 54617, which is insufficient to trigger Fast Retx. So an RTO is eventually seen. Either RTT measurements are incorrect (haven't checked this yet) or this is just an unfortunate use-case. 2. RTO, because ReTx Timeout is at times is equal to the delayed Ack Timeout of 200 ms. This is seen for seq # 190321 etc. Thus causing spurious timeouts. Here are RTOs for 3 possible variations For the default case : 11 Min RTO of 1 second : 2 Delayed ACK TO of 100 ms : 2 A min RTO of 1 second is recommended by RFC 2988
bug 1039 is actually a duplicate of this. I am going to leave both open for now; we should try to close.
The problem is due to the fact that the data sender would ignore all the old sequence numbers received without any ACK. So if the data receiver lost any ACK from the data sender, this phenomenon arises. This is wrong, so this is fixed in the patch in bug 1274.