Re: problem in newtimer() (?)

["Alhussein Abouzeid" <alhussein_abouzeid@hotmail.com>]

This problem sounds very much like one I had earlier last year. In my case, 
if a really long sequence of packet transmissions are lost
(whether in slows start or not), something happens that doesn't allow TCP to 
transmit again, even if I increase the simulation length to exceed 64*RTT 
(the value of the time-out period due to binary exponential back-off). I 
think the probelm might be in there, in the BEBO algorithm, but I didn't 
have the time to really go after this possible bug.

Hope this helps,

Hussein.


>From: Mark Allman <mallman@grc.nasa.gov>
>Reply-To: mallman@grc.nasa.gov
>To: ns-users@mash.cs.berkeley.edu
>Subject: problem in newtimer() (?)
>Date: Thu, 13 Jan 2000 12:14:37 -0500
>
>I think I have run across a bug in ns' one-way TCP implementation.
>I can only really produce this effect in a big simulation with lots
>of stuff going on, so I haven't been able to fully nail down what
>should be happening.  But, it goes something like this...
>
>We send a load of packets in slow start and they are nearly all
>lost.  Recovery happens naturally for a little while.  Then, things
>just end...  t_seqno_ is set to 406.  I get an ACK for 406.  This
>ACK doesn't let me transmit anything (using SACK versionof fast
>recovery).  However, according to TcpAgent::newtimer() I cancel the
>RTO timer, even though I have sent many more than 406 packets.  I
>get a duplicate ACK, which also doesn't let me transmit anything.
>Now, the transfer is done.  It is hung because there is no rexmt
>timer, I think.  So, I made a patch that seems to help the
>situation.  Here is my version of the newtimer() function.
>
>void TcpAgent::newtimer(Packet* pkt)
>{
>	hdr_tcp *tcph = hdr_tcp::access(pkt);
>#ifdef MALLMAN
>	if ((t_seqno_ > tcph->seqno()) || (tcph->seqno() < maxseq_))
>#else
>	if (t_seqno_ > tcph->seqno())
>#endif MALLMAN
>		set_rtx_timer();
>	else
>		cancel_rtx_timer();
>}
>
>In other words, we don't cancel the RTO timer if we have not
>received an ACK for the last thing we have sent.
>
>This seems to have fixed the problem.  However, I am not sure if
>that introduces other problems.  I'd appreciate some feedback on
>what this could effect.  Also, I can provide the packet traces I
>have if someone wants to dig into this a little more.
>
>allman

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com