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 PROTECTED] -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
