Bug 1227

Summary:	Spurious RTO due to low min RTO
Product:	ns-3	Reporter:	John Abraham <john.abraham.in>
Component:	tcp	Assignee:	Adrian S.-W. Tam <adrian.sw.tam>
Status:	RESOLVED FIXED
Severity:	major	CC:	ns-bugs, tomh
Priority:	P2
Version:	pre-release
Hardware:	All
OS:	All

Description John Abraham 2011-07-31 18:28:36 UTC

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

Comment 1 Tom Henderson 2011-08-09 15:12:02 UTC

bug 1039 is actually a duplicate of this.  I am going to leave both open for now; we should try to close.

Comment 2 Adrian S.-W. Tam 2011-09-29 12:57:59 UTC

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.