Protocol Profiles: Living TCP, Frozen TCP, and the Two Fast Paths

The tcp dropdown hides three decisions. F5's 13.0 announcement split the full-proxy family into living profiles it continually updates (read-only, tuned via children) and a frozen legacy trio that still ships. FastL4 trades the proxy for a hardware packet path, and FastHTTP is the narrow HTTP case that must clear every criterion on its list.

Open a virtual server's protocol profile list and BIG-IP offers a crowd: tcp, four names starting with f5-, three ending in -optimized, FastL4, FastHTTP. The crowd is really three families and three decisions, and every card in the L4 profile explainer belongs to one of them.

The full proxy, and the day its profiles started living

A standard virtual server is a full TCP proxy: two independent stacks, one negotiated with the client and one with the servers, which is what lets each side be tuned to its own link and what carries every feature the platform has. For years the tuning came as frozen presets, tcp-lan-optimized, tcp-wan-optimized, tcp-mobile-optimized, and their values aged as networks changed underneath them.

BIG-IP 13.0 reorganized the family, and F5's own announcement is worth reading in its original words: f5-tcp-wan, f5-tcp-lan, and f5-tcp-mobile are updated versions of the three -optimized profiles, adapting all settings to their link types without enabling the very newest features, and f5-tcp-progressive is a general-use profile, like the tcp default, carrying the very latest features for early adopters. The benchmark criteria published alongside were blunt: the link-tuned three achieved throughput at least as high, and often better, than default tcp for their link types, and progressive equal or higher across all representative network types.

The deeper change was the contract. Those four profiles, plus default tcp, became living: F5 continually updates them with best practices as they evolve, new features landing in progressive immediately and in the conservative living profiles a couple of releases later. And all five became read-only, so local tuning means creating a child profile, where checking the custom flag on a setting pins it against future pushes. That is the whole legacy-versus-living decision in one paragraph: the legacy trio still ships, listed beside the living family in the current profiles reference, frozen for configurations that depend on exact values, while the 's own upgrade path for anything new is the living four. One sizing footnote survives from the mobile pair: for objects under a megabyte, plain tcp-mobile-optimized generally beats mptcp-mobile-optimized.

The window the path needs

Tuning a TCP profile is often a question of window size. The v17 tmsh reference gives the tcp profile a receive-window-size of 65535 bytes and a send-buffer-size of 131072 bytes by default (tmsh reference: ltm profile tcp). 7323 states why the window matters on a long path: when the bandwidth-delay product, the path's rate multiplied by its round-trip time, exceeds 64 KiB, the receive window limits the maximum throughput, because it bounds the unacknowledged data TCP can send to keep the pipeline full (RFC 7323, section 1.1). At most one window is delivered per round trip, so a 100 Mbit/s path with an 80 ms round trip needs 1,000,000 bytes in flight, and a 64 KiB window carries at most about 6.6 Mbit/s across it. The lab below runs the same arithmetic for any path.

Interactive lab

Find what limits one TCP connection

Set the window a sender may have in flight, the round-trip time and the path's rate. The lab works out the most the window allows, the bytes the path needs in flight, and which of the two decides the throughput.

What happens

Window ceiling: 5.24 Mbit/s
Bandwidth-delay product: 1,250,000 bytes
Throughput: 5.24 Mbit/s, 5.2% of the path

Window: 64 KiB is 65,536 bytes the sender may have unacknowledged at once.
Ceiling: at most one window arrives per round trip, so 65,536 bytes every 100 ms is at most 5.24 Mbit/s.
Path: keeping 100 Mbit/s busy over a 100 ms round trip takes 1,250,000 bytes in flight, a window of at least 1,221 KiB.
Result: the window is the limit. The connection reaches 5.24 Mbit/s, 5.2% of the path, however fast the link is.

Filling this path takes more than 64 KiB in flight, which only the window scale option allows.

What the model leaves out: slow start and congestion avoidance, which keep the congestion window below this one at first; loss and retransmission; header overhead; delayed acknowledgements; and the buffers at either end. It treats the window as fixed and the path as clean.

FastL4: the profile that is not a proxy

The second decision abandons the proxy entirely. The profiles reference states FastL4's purpose plainly: assigning it lets the Packet Velocity hardware, where the platform supports it, process some or all of the Layer 4 traffic, and it pairs with Performance (Layer 4), Forwarding (Layer 2), and Forwarding (IP) virtual servers, with dynamic offload able to hand established flows to ePVA hardware mid-connection. The operations guide gives the when in a single clause, little or no or L7 processing required, and names the cost with equal economy: minimal L7 information is available, so decisions are limited in scope. Since 12.0.0 an HTTP profile can be attached to a Performance (Layer 4) virtual server, but K8082 is explicit that adding it does not change how the packets are processed: the virtual still works packet by packet, makes the load-balancing decision on the client's SYN and passes that SYN to the pool member, with no client-side handshake of its own. The same article notes that the r2000 and r4000 series carry no ePVA chip, so FastL4 runs entirely in software there. Which iRule events fire follows the profiles actually attached, the availability the event-order explainer flags.

The man page turns the card practical. The loose pair is the asymmetric-routing survival kit: loose-initialization accepts any TCP packet as connection initiation rather than requiring a SYN, loose-close tears down on the first FIN from either side, both default disabled. The pva-acceleration mode runs full, partial, dedicated, or none. Timestamp and window-scale handling default to preserve, the pass-through posture in two option defaults. And late-binding is the family's party trick: an iRule reads a Layer 7 FIX packet to select the pool, then hands the stream to the ePVA to carry at hardware latency, a FIX profile on the virtual server required.

FastHTTP: fast, narrow, and honest about it

The third decision is the narrow one. FastHTTP, per the reference, combines selected features from the TCP Express, HTTP, and OneConnect profiles into a single profile optimized for network performance, pairing with the Performance (HTTP) virtual server, and its signature benefit is connection reuse, the system transforming or adding the Connection header to keep server-side connections open, the same economics the OneConnect article walks in detail.

What makes the profile safe to recommend is that its qualification is a checklist the reference states outright: no remote server authentication, no SSL traffic management, no TCP optimizations, no compression, pipelining, or RAM Cache; no need to maintain source IP addresses; servers that support keep-alive, HTTP/1.1 or 1.0 with the header, by default; and basic iRule support only, the reference's own examples being CLIENT_ACCEPTED, SERVER_CONNECTED, and HTTP_REQUEST. Read backwards, every line disqualifies: terminate TLS, compress, cache, preserve client IPs, or run content-heavy iRules, and the answer is the standard virtual server with tcp and http profiles instead. The operations guide's verdict is the right closing note, possibly the fastest way to pass HTTP traffic under certain circumstances, with specific requirements and limitations, and K8024 as the reading you do before deploying, not after.

QUIC: a UDP client side on a Standard virtual server

adds a fourth arrangement, and it mixes the families instead of choosing one. F5's 21.1 procedure for web traffic over QUIC builds a Standard virtual server whose protocol is UDP: the client-side protocol profile is udp, the server-side protocol profile is a TCP profile (F5 recommends the default f5-tcp-lan), the client SSL profile is clientssl-quic, the HTTP MRF Router setting is enabled, and a QUIC profile and an HTTP3 profile complete the stack, with Auto Map as the source address translation (creating a virtual server for web traffic over QUIC). In F5's own summary, the virtual server listens for client traffic sent over QUIC and UDP, decrypts it, and forwards the decrypted traffic to the pool over TCP. The full proxy is what makes the split possible: QUIC is a client-side matter, and the server side stays an ordinary TCP profile choice from the families above.