Investigating the LTM TCP Profile: Timers

Introduction

The LTM TCP profile has over thirty settings that can be manipulated to enhance the experience between client and server.  Because the TCP profile is applied to the virtual server, the flexibility exists to customize the stack (in both client & server directions) for every application delivered by the LTM.  In this series, we will dive into several of the configurable options and discuss the pros and cons of their inclusion in delivering applications.

1. Nagle's Algorithm
2. Max Syn Retransmissions & Idle Timeout
3. Windows & Buffers
4. Timers
5. QoS
6. Slow Start
7. Congestion Control Algorithms
8. Acknowledgements
9. Extended Congestion Notification & Limited Transmit Recovery
10. The Finish Line

Quick aside for those unfamiliar with TCP: the transmission control protocol (layer 4) rides on top of the internet protocol (layer 3) and is responsible for establishing connections between clients and servers so data can be exchanged reliably between them. 

Normal TCP communication consists of a client and a server, a 3-way handshake, reliable data exchange, and a four-way close.  With the LTM as an intermediary in the client/server architecture, the session setup/teardown is duplicated, with the LTM playing the role of server to the client and client to the server.  These sessions are completely independent, even though the LTM can duplicate the tcp source port over to the server-side connection in most cases, and depending on your underlying network architecture, can also duplicate the source IP.

TCP Timers

TCP sets several timers (not all documented here) for each connection, and decrements them either by the fast timer function every 200ms or by the slow timer function every 500ms.  Several of the timers are dynamically calculated, but a few are static as well.  We’ve already discussed the idle timeout setting, so today we’ll tackle the FIN_WAIT, CLOSE_WAIT, & TIME_WAIT settings.  Reference these diagrams as you read through the timer settings below.  The diagram on the left represents a standard tcp close, and the the one on the right represents a simultaneous close.

FIN_WAIT

There are actually two FIN_WAIT states, FIN_WAIT_1 and FIN_WAIT_2.  In a standard close, the FIN_WAIT_1 state occurs when the initiator sends the initial FIN packet requesting to close the connection.  The FIN_WAIT_2 state occurs when the initiator receives the acknowledgement to its FIN and prior to receiving the FIN from the responder.  In a simultaneous close, both sides are initiators and send the FIN, creating the FIN_WAIT_1 state on both ends.  Upon receiving a FIN before receiving the ACK from its FIN, it immediately transitions to the closing state.  In the LTM TCP profile, the FIN_WAIT setting (in seconds) applies to both the FIN_WAIT and the CLOSING states, and if exceeded will enter the closed state.  The default setting is five seconds.

CLOSE_WAIT

 Whereas the FIN_WAIT states belong to the end of the connection initiating a close (called an active close), the CLOSE_WAIT state belongs to the end responding to a close request (called a passive close).  The CLOSE_WAIT state occurs after a responder receives the initial FIN and returns an acknowledgement.  If the responder does not receive an acknowledge from its FIN to the initiator before the timer is exceeded, the connection with enter the closed state.  Like the FIN_WAIT state, the default setting is five seconds.

TIME_WAIT

The TIME_WAIT state occurs as part of the active close on the initiator side of the connection when the final FIN is received and acknowledged, or in the case of a simultaneous close, when the acknowledgment to its initial FIN is received.  The default setting is 2000 milliseconds, so connections entering the TIME_WAIT state will enter the closed state after 2 seconds.

TIME_WAIT Recycle

This setting when enabled will signal the LTM to reuse the connection when a SYN packet is received in the TIME_WAIT state.  If disabled, a new connection will be established.