Every BIG-IP LTM - Local Traffic Manager virtual server carries a protocol profile, and the choice among them is really three decisions wearing one dropdown. This tool renders the candidates as cards, each grounded in F5's own sources: the story, when to use it, the tradeoffs, and the details worth memorizing.
The first decision is inside the full-proxy tcp family, and it is the living-versus-legacy split F5 announced with BIG-IP 13.0. The announcement's own words settle what the f5-* profiles are: f5-tcp-wan, f5-tcp-lan, and f5-tcp-mobile are updated versions of tcp-wan-optimized, tcp-lan-optimized, and tcp-mobile-optimized, adapting all settings to their link types without the very newest features, while f5-tcp-progressive is the general-use profile that carries the very latest features for early adopters. Those four, plus the default tcp, are living: F5 continually updates them with best practices, new features land in progressive immediately and in the conservative profiles a couple of releases later, and all five are read-only, so tuning means creating a child profile, where the custom flag pins any setting you never want a future update to touch. The legacy trio still ships, listed side by side with the living family in the current profiles reference, frozen for configurations that depend on exact values.
The second decision is FastL4, and the card is honest that it is not a TCP proxy at all: the profiles reference states its purpose as letting the Packet Velocity ASIC hardware, where the platform supports it, process some or all of the Layer 4 traffic, paired with Performance (Layer 4) and Forwarding virtual servers. The operations guide supplies the when in one clause, little or no L4 or L7 processing required, and the tradeoff in another, minimal L7 information is available, so load-balancing decisions are limited in scope. The man page supplies the knobs: the pva-acceleration modes, the loose-initialization and loose-close pair for asymmetric paths (any-TCP-packet initiation and first-FIN close, both default disabled), timestamp and window-scale modes defaulting to preserve, and late-binding, where an iRule reads a FIX packet to pick the pool and hands the stream to ePVA hardware.
The third is FastHTTP, defined by the reference as selected features of TCP Express, HTTP, and OneConnect combined into one profile, and qualified by a criteria list this card carries whole: no SSL traffic management, no compression, pipelining, or RAM Cache, no need to preserve source IPs, keep-alive-capable servers, and basic iRule support only, the reference's own examples being CLIENT_ACCEPTED, SERVER_CONNECTED, and HTTP_REQUEST. Read backwards, every criterion is a disqualifier, and the operations guide sends every deployment to K8024 first.
Reference posture like its BIG-IP Zero Trust Access (formerly BIG-IP APM - Access Policy Manager) sibling: cards and lookup now, stanza parsing with a per-option audit as the documented roadmap. Everything runs locally.