# Investigating the LTM TCP Profile: Timers **URL:** \ **Category:** F5 Technical Articles\ **Tags:** news, application-delivery, tech-tip, series-the-tcp-profile, tcp\ **Created:** [November 25, 2008, 5:36pm UTC](https://community.f5.com/t/investigating-the-ltm-tcp-profile-timers/68351 "2008-11-25T17:36:00Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![JRahm](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/jrahm/32/3327_2.png) [@JRahm](https://community.f5.com/u/JRahm)\ **Post date:** [November 25, 2008, 5:36pm UTC](https://community.f5.com/t/investigating-the-ltm-tcp-profile-timers/68351/1 "2008-11-25T17:36:00Z")
**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](https://community.f5.com/topic/288293) 2. [Max Syn Retransmissions & Idle Timeout](https://community.f5.com/topic/288152) 3. [Windows & Buffers](https://community.f5.com/topic/288156) 4. [Timers](https://community.f5.com/topic/288026) 5. [QoS](https://community.f5.com/topic/288183) 6. [Slow Start](https://community.f5.com/topic/288171) 7. [Congestion Control Algorithms](https://community.f5.com/topic/288065) 8. [Acknowledgements](https://community.f5.com/topic/288054) 9. [Extended Congestion Notification & Limited Transmit Recovery](https://community.f5.com/topic/288796) 10. [The Finish Line](https://community.f5.com/topic/288783) Quick aside for those unfamiliar with TCP: the [transmission control](http://en.wikipedia.org/wiki/Transmission_Control_Protocol) protocol (layer 4) rides on top of the [internet](http://en.wikipedia.org/wiki/Internet_Protocol) 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. ![0151T000003d7dnQAA.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/1/1163652b9d43cac1e354aacd03b55e3e557e9aac.jpeg)       ![0151T000003d7dmQAA.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/6/64ea14a4c95508aba16c4ddf0b677c4dafdfa744.jpeg) **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.