Subject: IPv6 MIB team: TCP-MIB in RFC2012 draft - tcpListenerTimeOuts

From: Kristine Adamson <[email-masked]>
Date: Fri, 14 Feb 2003 10:36:56 -0500

We have been looking into implementing TCP data from the version-neutral
RFC2012 draft. We have a question about when the tcpListenerTimeOuts
counter should be incremented given the following scenarios.  We assume the
counter should be incremented when the row is removed from the
tcpConnectionTable while in the synReceived state _only if_ the removal was
due to the retransmission of the SYN/ACK packets timing out.

If the route from the client to the server is working but the route from
the server back to the client is dropping packets, both the client and
server's TCP/IP stacks will begin retransmitting packets. The client will
retransmit the SYN packets and the server will retransmit the SYN/ACK
reply. Because the SYN/ACK packets are dropped, this will continue until
one or both sides time out. This can create unpredictable results as far as
what the tcpListenerTimeOut counter will be. Here are some possible
scenarios:

   a) The client and server retransmission intervals are approximately the
   same. The client times out first since it sent the first packet and
   sends a RST packet. The server receives the RST packet and removes the
   row from the tcpConnectionTable _before the server times out_. In this
   case the counter would _not_ be incremented at all.

   b) The client and server retransmission intervals are approximately the
   same. The client times out first since it sent the first packet and
   sends a RST packet. The server times out and removes the row from the
   tcpConnectionTable _before it processes the RST packet from the client_.
   In this case the counter would be incremented once.

   c) The client's retransmission interval have been configured to be
   longer than the server's intervals. The server might time out several
   times before the client eventually times out. When the server times out,
   it does send a RST packet, but because the packets are being dropped
   along this route, the client never receives the RST and continues to
   resend SYN packets. When the resent SYN is received by the server which
   just removed a row for the same local/remote IP address and port, it
   treats this packet as a new request and creates a new row in the
   tcpConnectionTable in synReceived state. The server could time out
   multiple times before the client times out causing the
   tcpListenerTimeOut counter to be incremented multiple times for a single
   connect() request.

Is our understanding of when this counter is to be incremented correct?  In
the above scenarios, will the value reflect what the tcpListenerTimeOuts
MIB object was intended to count?

Thanks,

Kristine Adamson
IBM Communications Server for MVS: TCP/IP Development
Internet e-mail:[email-masked]

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------