Every virtual server needs at least one protocol profile at the transport layer. For TCP-based applications that means either a full-proxy tcp profile (the workhorse behind Standard virtual servers) or one of the accelerated, packet-based profiles: fastL4 or fasthttp. Understanding when to reach for each one, and which defaults actually matter, is a recurring theme on the LTM exam.

TCP profile: the full-proxy workhorse

A Standard virtual server terminates the client-side TCP connection completely and opens an independent server-side TCP connection to the pool member. This full-proxy architecture is what allows the BIG-IP system to apply L7 profiles (HTTP, SSL, compression, and so on) on top, and to optimize each side of the connection independently — for example, a slow WAN client and a fast LAN server can each get buffer and congestion settings tuned for their own network characteristics (this is exactly what the f5-tcp-wan and f5-tcp-lan parent profiles do).

Two settings that the exam likes to probe are Minimum RTO and Congestion Control:

Minimum RTO (Retransmission Timeout) defaults to 1000 ms, with a valid range of 0–5000 ms. This is the floor on how long the system waits for an ACK before retransmitting. F5 notes this is the RFC-compliant value of one second. If Packet Loss Ignore Rate/Burst are non-zero, the effective floor drops to 203 ms; with MPTCP enabled it drops to 200 ms.
Congestion Control defaults to High Speed on the base tcp parent profile — a more aggressive, loss-based algorithm suited to high-bandwidth links (RFC 3649). Other selectable algorithms include CUBIC, BBR (14.1.0+), New Reno, Reno, Illinois, Vegas, Westwood+, CAIA Delay-Gradient (CDG), CAIA Hamilton Delay (CHD), Scalable, and Woodside. The specialized parent profiles change this default: f5-tcp-wan, f5-tcp-lan, and f5-tcp-progressive all default to Woodside, which targets high-speed, long-distance links with enhanced congestion recovery.

Other TCP profile defaults worth memorizing: Idle Timeout is 300 seconds, Time Wait is 2000 ms, Max Segment Size is 1460 bytes, and Selective ACKs, Delayed ACKs, and Nagle's Algorithm (disabled on the base profile) each affect throughput characteristics in ways F5 recommends you leave alone unless you have a specific, measured reason to change them.

Setting	Default	Why it matters
Minimum RTO	1000 ms (range 0-5000)	Floor before the system resends unacknowledged data; lower values recover faster on lossy/high-RTT links but risk spurious retransmits
Congestion Control	High Speed (base profile)	Determines how aggressively the send window grows/shrinks under loss
Idle Timeout	300 sec	How long a connection with no traffic stays in the table before eligible deletion
Time Wait	2000 ms	How long a closed connection lingers in TIME-WAIT before recycling
Max Segment Size (MSS)	1460 bytes (0 = derive from MTU)	Largest single-segment payload, excludes TCP/IP headers
Selective ACKs (SACK)	Enabled	Lets the sender retransmit only the missing segments instead of everything after a loss
Proxy Buffer Low / High	196608 / 262144 bytes	Controls content spooling — how much data BIG-IP buffers when client/server speeds mismatch

Send buffer, proxy buffer, and the zero-window problem

Because a Standard virtual server is a full proxy, BIG-IP must hold data in memory whenever the two sides of a connection run at different speeds — a fast server feeding a slow client, or the reverse. Two buffers govern this. The send buffer (send-buffer-size) is how much outbound data TMM will queue for one side. The proxy buffer, controlled by the Proxy Buffer High and Proxy Buffer Low watermarks, is the aggregate spool between the client side and the server side.

The proxy buffer acts as a flow-control throttle. When buffered, not-yet-delivered data climbs to Proxy Buffer High (default 262144 bytes), BIG-IP stops reading from the fast side — effectively advertising a TCP zero window so that sender pauses. When the buffer drains back down to Proxy Buffer Low (default 196608 bytes), BIG-IP resumes reading and re-opens the window. The reason High must sit well above Low — F5 recommends roughly a 64 KB gap, which is exactly the 65536-byte spread between the two defaults — is hysteresis: the gap gives the buffer room to breathe between the “stop” and “start” signals. If the two watermarks were close together, the buffer level would bounce back and forth across a single threshold and the connection would flap in and out of the zero-window state, producing a storm of window updates and destroying throughput. The wide gap is deliberate.

A subtlety the exam can exploit: through TMOS v12.1, the configured send-buffer-size limit does not apply when the system variable tm.tcpprogressive.autobuffertuning is enabled (the default) and at least one profile attribute such as MPTCP, Rate Pacing, Tail Loss Probe, or TCP Fast Open is set. In that case BIG-IP sizes the send buffer dynamically and ignores your fixed ceiling — so if send-buffer-size appears to have no effect, this auto-tuning interaction is the usual cause.

Maximum Segment Retransmissions (DoS protection)

The TCP profile's Maximum Segment Retransmissions setting caps how many times a single data segment may be retransmitted before TMM gives up and resets the connection. The default is eight. This is a resource-protection knob: during a DoS condition where many half-broken flows all retransmit endlessly, letting each retry forever would starve TMM of memory, so capping retransmits and resetting sheds the dead flows. The companion Maximum SYN Retransmissions setting applies the same logic to the SYN of an embryonic (not-yet-established) connection.

FTP profile

FTP is awkward to load balance because it negotiates a separate data channel dynamically over the control channel. The FTP profile teaches BIG-IP to parse the control connection, track the negotiated data-channel port, and open the matching flow. Two settings worth memorizing: Data Port defaults to 20 (the standard active-mode FTP data port), and FTPS Mode governs whether FTP-over-TLS is permitted. When FTPS Mode is set to Disallow (the strictest option), BIG-IP resets the connection of any client that sends AUTH SSL or AUTH TLS to start FTPS, and it does not respond to FEAT commands from FTPS clients — contrast with Allow (permit either plaintext or FTPS) and Require (force FTPS).

UDP profile

UDP is connectionless, so “load balancing a UDP flow” is really a question of how BIG-IP groups datagrams into a pseudo-connection. The UDP profile governs that. Its most important setting is Datagram LB: when disabled (the default), BIG-IP treats a source/destination pairing as a single flow and load-balances the first datagram, then pins subsequent datagrams to the same pool member for the life of the (idle-timeout-bounded) flow — the right behavior for session-oriented UDP like DNS-over-UDP with retries or RADIUS. When Datagram LB is enabled, every datagram is load-balanced independently, which suits true fire-and-forget, stateless UDP (syslog, some telemetry) but is incompatible with any per-flow feature. The UDP profile also has its own Idle Timeout (default 60 seconds, much shorter than TCP's 300, because there is no FIN to signal the end of a UDP conversation) and an Allow No Payload option. UDP is one of the four transport profile types (TCP, UDP, SCTP, FastL4) a virtual server can be built on.

Deferred Accept (TCP profile, DoS mitigation)

The TCP profile's Deferred Accept option (disabled by default) tells BIG-IP not to complete the server-side connection or allocate full flow resources until the client actually sends data after the handshake. It blunts a class of attack where an attacker completes the 3-way handshake but never sends a request, tying up resources. The trade-off — and an exam-worthy caveat — is that Deferred Accept is not compatible with some applications, particularly server-speaks-first protocols (SMTP, SSH, some databases) where the server is supposed to send the first bytes; enabling it there breaks the connection.

FastL4 profile: hardware-accelerated L4

FastL4 skips the full-proxy TCP stack. Instead of terminating and re-originating the connection, the BIG-IP system inspects and forwards packets at Layer 4, optionally offloading the flow to the ePVA (embedded Packet Velocity ASIC) hardware chip on platforms that have one. This delivers very high throughput and very low latency, but at the cost of losing L7 visibility and full-proxy optimizations. FastL4 is used with Performance (Layer 4), Forwarding (Layer 2), Forwarding (IP), and Internal virtual server types.

Key FastL4 settings and defaults:

Setting	Default	Notes
Idle Timeout	300 sec	Same concept as the TCP profile idle timeout, but for the accelerated flow
TCP Handshake Timeout	5 sec	How long the 3-way handshake is allowed to complete before the system gives up
Reset on Timeout	Enabled	Sends RST to both sides when idle timeout is exceeded rather than silently dropping state
SYN Cookie MSS	0 (no override)	Overrides the MSS advertised in the SYN-ACK sent on behalf of a backend server during a SYN cookie challenge; valid values 0 or 256-9162. Useful when the real backend's MSS differs from BIG-IP's own default (1460)
SYN Challenge Handling	Nominal	Controls when SYN cookie challenges kick in to mitigate embryonic-connection (SYN flood) attacks
Loose Initiation / Loose Close	Disabled	Allows the system to open/close connection table entries without seeing a SYN/FIN on both sides — useful for asymmetric routing, but F5 recommends enabling both together
PVA Acceleration	Full	Governs how aggressively the ePVA hardware chip offloads the flow

Use FastL4 only when you don't need L7 features such as HTTP header manipulation, SSL offload, compression, or persistence based on cookies. Any setting that forces packet inspection — enabling Reassemble IP Fragments, setting IP ToS to anything other than Pass Through, and so on — demotes the flow from hardware acceleration back to software, eroding the very performance benefit you chose FastL4 for.

DSR and nPath routing (FastL4's signature use case)

The reason FastL4 exists in many designs is Direct Server Return (DSR), also called nPath routing. In a normal full-proxy flow, both the request and the response pass back through BIG-IP. With DSR, only the inbound request goes through BIG-IP; the server sends its response straight back to the client, bypassing BIG-IP entirely. This slashes the load on BIG-IP for response-heavy workloads (video, large downloads), because the box never touches the (usually much larger) return traffic.

The trade-off is that DSR is a Layer 4–only technique: because BIG-IP never sees the response, it cannot do SSL termination, HTTP inspection, cookie persistence, or any L7 work — it can only load balance at Layer 4. Two mechanics make it work. In Layer 2 nPath, BIG-IP forwards the request to the server without translating the destination IP, so the content servers must have their default route set to the router's internal address (not to BIG-IP) and a loopback configured with the virtual server's address so they accept the packet. And because the return path is invisible to BIG-IP, you enable Loose Close on the FastL4 profile so the connection's flow state expires more quickly after a TCP FIN is seen, rather than waiting on a full teardown BIG-IP will never fully observe.

Fast HTTP profile

Fast HTTP sits between FastL4 and the full HTTP profile: it combines the most commonly used features of TCP, HTTP, and OneConnect into a single, packet-by-packet profile optimized for CPU and latency. It automatically applies SNAT to all connections and folds in a lightweight OneConnect-style connection-reuse mechanism, including transforming Connection: close on HTTP/1.0 requests so the server-side connection remains eligible for reuse.

Fast HTTP trades away a long list of features: no IPv6, no SSL offload, no compression, no caching, no PVA acceleration, no HTTP pipelining, no state mirroring, and only limited iRules support restricted to L4 and a subset of HTTP header operations. It also drops out-of-order packets that contain HTTP headers, forcing a client retransmit, and only supports static-text header insertion (no iRule variable expansion). F5's guidance is explicit: use Fast HTTP only for well-behaved traffic on clean networks — load generators, internal LAN-to-LAN traffic, and similar — and use the standard HTTP profile for general Internet-facing load balancing where packet loss and reordering are a fact of life.