FastL4 vs Optimized TCP Profiles

I have not done a direct comparison but in general the TCP LAN Optimized profile seems to work very well for reducing latency, even for clients not on the LAN (I have used it on applications where the average latency from the client is ~600ms and it still improved response time greatly).

 

 

Denny

If you're only decisive at layer 4 and below (and you don't need oneconnect), fastL4 is the way to go as it utilizes the Packet Velocity asic on your hardware (though only in assist mode in your case since you're using snat). If you want to optimize http in any way, you'll need the tcp+http profile combination. I've done this with the lan-optimized profile with 20000 connections/second at 300 Mbps traffic on a 3400 (single processor) and CPU never hit 15% and the memory utilization never climbed above 400MB. The 6400 is rated much much higher than that, so unless you are currently really pushing the box, you should be fine with the optimized profile. I would recommend the LAN optimized, even with the WAN environments, it has worked well for me and I've heard the same from other users that it performs better. Your mileage may vary, so test if you can, set up a vip in parallel that you can push X percentage of users to for piloting.

We are not pushing the box at all right now. CPU and memory utilization are relatively low. I assumed FastL4 would be best since it processes the traffic in hardware. Same reasons switches operate faster than routers (hey, I am a network engineer!). When you say "if you want to optimize http in any way", do you mean for those VIP's where FastL4 is not an option ? Most of our VIPs will be able to use FastL4 but for those that can not we will definitely move to LAN Optimized on both sides. Thanks again. I really hope this makes a difference.

your biggest help will be in the windowing and proxy buffers. To give you a real world, when I replaced a local director with the LTM, the performance dropped across the board, increasing the front page paints by 100% (yes, that bad). first thought was what the heck is wrong with this fancy new gear? Turns out nothing...the local director did nothing to TCP except port mapping and the web servers tcp stacks had been tuned. Well, the LTM is a full proxy, so all that tuning was now gone in reference to the client. Once we tuned the stack on the LTM, not only did performance come back in line across the board, but improved significantly in some areas with no noticable change in LTM performance. If you check the docs section of this site, I've been writing a series on the tcp profile

 

 

I was basically in the same position as you about a year ago. By doing a lot of tcp trace analysis, I was able to conclude that basically the LTM was throttling down all of our application traffic - much the same way yours is. It took a lot of studying and analysis, but I eventually came out with a TCP profile that is no longer throttling the connections. From my perspective, here are the most important settings:

 

 

Proxy Buffer Low: 98304

 

Proxy Buffer High: 131072

 

Send Buffer: 65535

 

Receive Window: 65535

 

Slow Start: disabled

 

Nagle's Algorithm: disabled

 

 

This tcp profile used for both our Client and Server connections. First I adjusted the four buffer settings. Next, I disabled Nagle. Finally I disabled Slow Start. Each individual step in that process significantly improved our TCP performance.

 

 

Like you, I was also concerned about CPU/memory utilization when adjusting these parameters (our platform is also 6400s). One of our pairs has a max number of connections of 1.5 million, and pushes over 500Mbps at times. And I haven't seen any noticable change to the CPU or memory utilization after these tcp profile adjustments. But to be honest, it was a leap of faith to get there. I couldn't come up with any way to measure the potential impact. The good news is that the changes don't disrupt traffic processing, and it is very easy and quick to back out.

 

 

What I concluded in a general sense is, with the default tcp profile settings, the LTM sends a limited number of data packets to the client before it sits and waits for an acknowledgement. On a circuit with an 80ms delay, this time adds up quickly. By changing the tcp parameters to the ones I noted above, the LTM now tries to fill up the entire client receive window resulting in much higher throughput.

"Throttling down" is not a shortcoming in the product, it's really the LTM's tcp stack complying with the configuration in the system. I had a table in my tech tip on windows and buffers (http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=287 Click here) that presents a table that shows the practical max throughput numbers at various window sizes and latencies, and it's really shocking how poor throughput is when latency grows even a little bit, and that's not even taking into account loss. A small congestion window can really hamper a tcp sender's ability to deliver data due to the nature of tcp being a reliable transport protocol, which requires feedback from the receiver before pushing too much data at once.

LTMs are astoundingly robust - I continue to be amazed at how well they perform. I definitely did not mean to imply there were any shortcomings in the product. The throttling was absolutely due to the way we had configured the TCP profile (or more accurately, did not configure the TCP profile).

 

 

And the articles you wrote are an excellent resource. Thank you for them. I have referenced them many times already.

Oh, I didn't take it that way at all, just clarifying. Thanks for feedback, and if you have any other product features you'd like me (or one of the other guys) to write a series on, let me know.

Thanks for the quick and detailed responses. Still though, I am not sure which one to use (FastL4 or Optimized). We are already moving a single VIP over to FastL4 on Tuesday morning. Doing so will put more of a burden on the physical servers themselves, correct ? That's why I am leaning towards using the optimized profile but obviously I want whatever is fastest and most efficient. Maybe after a week of running on FastL4, I'll see about switching it over to the TCP optimized profile to compare the results.... Thanks once again !

Citizen will probably give you a better answer than this. But if it were me, I would ask myself whether or not I need the LTM to do any manipulation of the traffic. For example if this were an HTTP application, would I need to use iRules to read the URI or headers? If the LTM doesn't need to look this high into the packet, then I'd use a FastL4.

 

 

I think all else being equal, FastL4 is faster.