Bug 1227 - Spurious RTO due to low min RTO
Spurious RTO due to low min RTO
Product: ns-3
Classification: Unclassified
Component: tcp
All All
: P2 major
Assigned To: Adrian S.-W. Tam
Depends on:
  Show dependency treegraph
Reported: 2011-07-31 18:28 EDT by John Abraham
Modified: 2011-12-10 21:31 EST (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description John Abraham 2011-07-31 18:28:36 EDT
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 EDT
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 EDT
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.