[Ns-bugs] [Bug 1009] Tx Sequence number assert fail in TCP

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=1009





--- Comment #1 from Bill Roome <wdr at bell-labs.com>  2010-10-18 10:02:23 EDT ---
When 100's of TCP connections are created and closed on a slow network,
occasionally this assert fails (tcp_socket_impl.cc, line 1024, 3.9 released):

bool TcpSocketImpl::ProcessPacketAction (...)
{
  .....
    case NEW_ACK:
      .....
        NS_ASSERT(tcpHeader.GetAckNumber ()  <= m_nextTxSequence);

It seems like the problem is in the following code, which sets m_nextTxSequence
to the sequence number saved in m_finSequence (lines 945-953 in 3.9 released):

bool TcpSocketImpl::ProcessPacketAction (...)
{
  ....
    case ACK_TX:
      NS_LOG_LOGIC ("TcpSocketImpl " << this <<" Action ACK_TX");
      if(tcpHeader.GetFlags() & TcpHeader::FIN)
      {
        ++m_nextRxSequence; //bump this to account for the FIN
        m_nextTxSequence = m_finSequence;
      }
      SendEmptyPacket (TcpHeader::ACK);
      break;

There seem to be two problems with that. First, very often m_finSequence is 0,
indicating that it had never been set. Second, sometimes m_finSequence is less
than the current m_nextTxSequence. Often it's only 1 less, which seems to be
okay. However, once in a while it's 100's of packets less than
m_nextTxSequence.

I worked around the problem by making two changes to that block. First, if
m_finSequence is 0, I just ignore it -- I don't set m_nextTxSequence. Second,
if m_finSequence is less than m_nextTxSequence, I also ignore it.

Eg, I changed that to:

    case ACK_TX:
      NS_LOG_LOGIC ("TcpSocketImpl " << this <<" Action ACK_TX");
      if(tcpHeader.GetFlags() & TcpHeader::FIN)
      {
        ++m_nextRxSequence; //bump this to account for the FIN
        if (m_finSequence == g_zeroSeqn)
          {
            NS_LOG_ERROR("TcpSocketImpl::ProcessPacketAction: ACK_TX+FIN
finSeqn==0 ERROR:"
                         << " m_nextTxSequence=" << m_nextTxSequence);
          }
        else if (m_finSequence < m_nextTxSequence)
          {
            NS_LOG_ERROR("TcpSocketImpl::ProcessPacketAction: ACK_TX+FIN
SEQUENCE ERROR:"
                         << " m_finSequence=" << m_finSequence
                         << " m_nextTxSequence=" << m_nextTxSequence);
          }
        else
          {
            m_nextTxSequence = m_finSequence;
          }
      }
      SendEmptyPacket (TcpHeader::ACK);
      break;

With those changes, everything works okay.

I realize this might not be the best solution; I'll leave it to someone who's
more familiar with this code and TCP to decide whether this cures the disease
or just treats the symptoms.

Of course, if you decide it's curing the disease, it would be better to add an
explicit "m_finSequenceHasBeenSet" flag rather than assuming that 0 is always
an invalid sequence number.

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.