Bug 1509

Summary:	RttEstimator returns invalid value in presence of errors
Product:	ns-3	Reporter:	Tom Henderson <tomh>
Component:	internet	Assignee:	Brian Swenson <bswenson3>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ns-bugs, riley
Priority:	P5
Version:	pre-release
Hardware:	All
OS:	All
Attachments:	testcase

Description Tom Henderson 2012-10-05 19:40:11 UTC

Reported by Siddharth Gangadhar.

 strange behavior with RTT estimation over a wired link in the presence of errors. Sometimes, the RTT estimated is shown to be zero although the one way propagation delay is set to be 102ms. 

I had posted this along with extra details and logs on the ns-3 users list and can be accessed at https://groups.google.com/forum/?fromgroups=#!topic/ns-3-users/OTlDUvh2o7Q%5B1-25%5D.

Comment 1 Tom Henderson 2012-10-05 19:41:56 UTC

Created attachment 1452 [details]
testcase

Need to add logging to tcp-socket-base as follows:

 I also logged the TcpSocketBase:EstimateRtt function using NS_LOG_FUNCTION (this << m_lastRtt);

Given below are the excerpts from the logs where I see RTT being set to zero in case 1 and not zero in case 2. Both are from the same simulation. 

Case 1: [node 0] TcpSocketBase:EstimateRtt(0x2488110, +0.0ns)
Case 2: [node 0] TcpSocketBase:EstimateRtt(0x2488110, +201020797.0ns)

Comment 2 Brian Swenson 2012-11-05 14:12:30 UTC

9118:5991df10eb5e

RTT Estimator was returning 0 when it detected there was a duplicate ack number that was passed into it.  This is desired because dup acks should not be modifying RTT estimate.  TCPSocketBase now correctly interprets this return value and does not update the last RTT sample in the case of a dup ack.