[Ns-developers] ns-2.34: TcpAgent negative RTO! error
L.Wood at surrey.ac.uk
Tue Jun 15 02:11:46 PDT 2010
Thanks, Tom. Including your code snippet in ns-2.34 stopped the overflow, and stopped t_backoff going above 64 (which makes sense with a maxrto_ of 60).
I see you committed
to tcp.cc in April 2010, so this fix hasn't yet reached an ns release.
From: Tom Henderson [mailto:tomh at tomh.org]
Sent: 15 June 2010 05:42
To: Wood L Dr (Electronic Eng)
Subject: Re: [Ns-developers] ns-2.34: TcpAgent negative RTO! error
On 6/14/10 10:18 AM, L.Wood at surrey.ac.uk wrote:
> I've been able to hit the TcpAgent: negative RTO! error-and-exit reliably and repeatedly in ns-2.34.
> (I see from googling that this has cropped up for years; advice seems to default to 'well, don't run your simulations that long').
> So, I instrumented the code in tcp.cc, when entering and leaving rtt_backoff(), and saw:
> t_backoff is 262144
> t_backoff changed to 524288
> t_backoff is 65536
> t_backoff changed to 131072
> t_backoff is 8
> t_backoff changed to 16
> t_backoff is 512
> t_backoff changed to 1024
> t_backoff is 67108864
> t_backoff changed to 134217728
> t_backoff is 1073741824
> t_backoff changed to -2147483648
> TcpAgent: negative RTO! (-6442450944.000000) maxrto_ 60.000000
> minrto_ 1.000000 t_rtxcur_ 3.000000 t_backoff_ -2147483648
> So yes, maxrto_ is at a limit of 60 per RFC2988, but t_backoff_ is just left to integer overflow, which strikes me as wrong.
> If maxrto_ hits 60, shouldn't t_backoff be reset to something sensible, or at least limited from overflowing?
Can you tell how t_backoff gets so high? This code suggests to me that it shouldn't grow that high:
if (t_backoff_ < 64 || (rfc2988_ && rtt_timeout() < maxrto_))
t_backoff_ <<= 1;
because rtt_timeout() should equal maxrto_ if clamped.
More information about the Ns-developers