Investigating the LTM TCP Profile: Max Syn Retransmissions & Idle Timeout

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.

Max Syn Retransmission

This option specifies the maximum number of times the LTM will resend a SYN packet without receiving a corresponding SYN ACK from the server.  The default value was four in versions 9.0 - 9.3, and is three in versions 9.4+.  This option has iRules considerations with the LB_FAILED event.  One of the triggers for the event is an unresponsive server, but the timeliness of this trigger is directly related to the max syn retransmission setting.  The back-off timer algorithm for SYN packets effectively doubles the wait time from the previous SYN, so the delay grows excessive with each additional retransmission allowed before the LTM closes the connection:

Tuning this option down may result in faster response on your LB_FAILED trigger, but keep in mind the opportunity for false positives if your server gets too busy.  Note that monitors are the primary means to ensure available services, but the max syn retransmission setting can assist.  If the LB_FAILED event does trigger, you can check the monitor status in your iRule, and if the monitor has not yet been marked down, you can do so to prevent other new connections from waiting:

when LB_FAILED {
    if { [LB::status pool [LB::server pool] member [LB::server addr] eq "up"] } {
        LB::down
    }
}

 Idle Timeout

 The explanation of the idle timeout is fairly intuitive.  This setting controls the number of seconds the connection remains idle before the LTM closes it.  For most applications, the default 300 seconds is more than enough, but for applications with long-lived connections like remote desktop protocol, the user may want to leave the desk and get a cup of coffee without getting dumped but the administrators don't want to enable keepalives.  The option can be configured with a numeric setting in seconds, or can be set to indefinite, in which case the abandoned connections will sit idle until a reaper reclaims them or services are restarted.  I try to isolate applications onto their own virtual servers so I can maximize the profile settings, but in the case where a wildcard virtual is utilized, the idle timeout can be set in an iRule with the IP::idle_timeout command:

when CLIENT_ACCEPTED {
    switch [TCP::local_port] {
        "22" {
            IP::idle_timeout 600
        }
        "23" {
            IP::idle_timeout 600
        }
        "3389" {
            IP::idle_timeout 3600
        }
        default {
            IP::idle_timeout 120
        }
}

 If you look at the connection table, the current and the maximum (in parentheses) idle values are shown:

b conn client 10.1.1.1 show all | grep –v pkts

 VIRTUAL 10.1.1.100:3389 <-> NODE any6:any

    CLIENTSIDE 10.1.1.1:36023 <-> 10.1.1.100:3389

    SERVERSIDE 10.1.1.100:36023 <-> 10.1.1.50:3389

     PROTOCOL tcp   UNIT 1   IDLE 124 (3600)   LASTHOP 1 00:02:0a:13:ef:80

Next week, we'll take a look at windows and buffers.