Bug 1509 – RttEstimator returns invalid value in presence of errors

Bug 1509 - RttEstimator returns invalid value in presence of errors


Summary:	RttEstimator returns invalid value in presence of errors

Status:	RESOLVED FIXED

Product:	ns-3
Classification:	Unclassified
Component:	internet
Version:	pre-release
Hardware:	All All

Importance:	P5 normal
Assigned To:	Brian Swenson

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2012-10-05 19:40 UTC by Tom Henderson
Modified:	2012-11-05 14:12 UTC (History)
CC List:	2 users (show)

See Also:

Attachments
testcase (6.76 KB, text/plain) 2012-10-05 19:41 UTC, Tom Henderson	Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

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.