tcp retransmission timeout

[Conor Cahir]

Hi, 

I've been using ns3 a lot recently and have just spent a couple of hours tracking down the source of a bug which should not have taken so long to find. I though it might be worth bringing this to the attention of the group to see if anything can be done about it.

I was given the following error message after trying to run a simulation:

"assert failed. cond="tAbsolute.IsPositive ()", file=../src/core/model/default-simulator-impl.cc, line=195"

Not very informative, especially considering the source of the bug. Actually, I had just made a dumb mistake when setting up my network topology. What this meant was that the tcp logic in ns3 entered an infinite loop of trying to retransmit the same packet. Since the correct behaviour is to double the retransmission time out on each failed attempt, eventually this number was so large that it became negative when treated as a signed integer, hence the failed assertion.

In order to figure out what was happening I had to literally dig into the core of ns3, but it surely wouldn't be difficult for ns3 to have figured out what was happening and told me the packet could not be transmitted, instead of failing most ungracefully with a cryptic error message. After all, someone may even want to simulate a situation where a packet is deliberately unable to be transmitted, but the simulator would just crash.

Is there any way to set a maximum retransmission time out? When this is reached a useful error message could be passed to the programmer. If not, might be a good idea, and if so should this not be set to some reasonable value by default?

Cheers

Conor

[Adrian Tam]

The retransmission time out is computed by RttEstimator, you can try
hack into that if you want to put a limit on to that. Another way to
do is to check for the retransmission timeout value
(TcpSocketBase::m_rto) upon every update. By the way, you sure m_rto
has a overflow? That should be a huge value to make it.