Technical Articles
F5 SMEs share good practice.
cancel
Showing results for 
Search instead for 
Did you mean: 
Martin_Duke
Legacy Employee
Legacy Employee

0151T000003d6bgQAA.png

[Update 1 Mar 2017: F5 has new built-in profiles in TMOS v13.0. Although the default profile settings still haven't changed, there is good news on that from as well.]

If the customer data I've seen is any indication, the vast majority of our customers are using the base 'tcp' profile to configure their TCP optimization. This has poor performance consequences and I strongly encourage you to replace it immediately.

What's wrong with it?

The Buffers are too small. Both the receive and send buffers are limited to 64KB, and the proxy buffer won't exceed 48K . If the bandwidth/delay product of your connection exceeds the send or receive buffer, which it will in most of today's internet for all but the smallest files and shortest delays, your applications will be limited not by the available bandwidth but by an arbitrary memory limitation.

The Initial Congestion Window is too small. As the early thin-pipe, small-buffer days of the internet recede, the Internet Engineering Task Force (see IETF RFC 6928) increased the allowed size of a sender's initial burst. This allows more file transfers to complete in single round trip time and allows TCP to discover the true available bandwidth faster.

Delayed ACKs. The base profile enables Delayed ACK, which tries to reduce ACK traffic by waiting 200ms to see if more data comes in. This incurs a serious performance penalty on SSL, among other upper-layer protocols.

What should you do instead?

The best answer is to build a custom profile based on your specific environment and requirements. But we recognize that some of you will find that daunting! So we've created a variety of profiles customized for different environments. Frankly, we should do some work to improve these profiles, but even today there are much better choices than base 'tcp'.

If you have an HTTP profile attached to the virtual, we recommend you use tcp-mobile-optimized. This is true even if your clients aren't mobile. The name is misleading! As I said, the default profiles need work.

If you're just a bit more adventurous with your virtual with an HTTP profile, then mptcp-mobile-optimized will likely outperform the above. Besides enabling Multipath TCP (MPTCP) for clients that ask for it, it uses a more advanced congestion control ("Illinois") and rate pacing. We recognize, however, that if you're still using the base 'tcp' profile today then you're probably not comfortable with the newest, most innovative enhancements to TCP. So plain old tcp-mobile-optimized might be a more gentle step forward.

If your virtual doesn't have an HTTP profile, the best decision is to use a modified version of tcp-mobile-optimized or mptcp-mobile-optimized. Just derive a profile from whichever you prefer and disable the Nagle algorithm. That's it! If you are absolutely dead set against modifying a default profile, then wam-tcp-lan-optimized is the next best choice. It doesn't really matter if the attached network is actually a LAN or the open internet.

Why did we create a default profile with undesirable settings?

That answer is lost in the mists of time. But now it's hard to change: altering the profile from which all other profiles are derived will cause sudden changes in customer TCP behavior when they upgrade. Most would benefit, and many may not even notice, but we try to not to surprise people.

Nevertheless, if you want a quick, cheap, and easy boost to your application performance, simply switch your TCP profile from the base to one of our other defaults. You won't regret it.

Comments
Lee_Payne_53457
Cirrostratus
Cirrostratus
Very interesting, I always assumed that the TCP profile was optimized in some way to provide a trade off between speed and device performance, time to go look at all of our VS's now and try to change them over.
Martin_Duke
Legacy Employee
Legacy Employee
Hi Lee, The 'tcp' profile is pretty old, and I'm sure there were good reasons for the settings. But in the modern internet the settings are pretty archaic.
Is there any documentation around on which tcp profiles should be used in what circumstances? We're in a similar boat to Lee, and i'm looking to see what profiles are best for us to update to.
Martin_Duke
Legacy Employee
Legacy Employee
Hi Andrew, We have a project to improve the profiles, to make choices easier, as well as publish better guides for creating your own profiles. You can learn more about configuration options through both online help and by poking around previous articles about the TCP profile, both by me and others. If you're looking for a very quick summary I'd just follow the advice under "What should you do instead?" above.
Martin_Duke
Legacy Employee
Legacy Employee
Andrew, I also should refer you to these two white papers about tuning your TCP profile: Optimize WAN and LAN Application Performance with TCP Express TCP Optimization for Service Providers
Nobumichi_Atobe
Nimbostratus
Nimbostratus
Hi there. Do you think applying this recommendation will improve SSL-VPN by APM? Also would this improve the throughput of applications transmitting over the SSL-VPN tunnel? I have read this page and the white paper Martin shared here but not 100% sure if this is effective for APM.
Carl_Brothers
F5 Employee
F5 Employee
Nobumichi, I think that this is very relevant for the SSL VPN use case as well. Remember that all of this rides over TCP in the end.
Walter_Kacynski
Cirrostratus
Cirrostratus
I've noticed that the Hardware SYN Cookie protection option has been disabled in the default mptcp-mobile-optimized profile. Why is that?
Martin_Duke
Legacy Employee
Legacy Employee
I've noticed that the Hardware SYN Cookie protection option has been disabled in the default mptcp-mobile-optimized profile. Why is that?

 

The mptcp-mobile-optimized protocol enables MPTCP, which is incompatible with hardware syn cookies.
ge0ff73_32053
Nimbostratus
Nimbostratus
I understand this profile will be applied to the Client Protocol Profile. Should we also apply this to the Server Protocol Profile for a LAN connected server pool?
Martin_Duke
Legacy Employee
Legacy Employee
I understand this profile will be applied to the Client Protocol Profile. Should we also apply this to the Server Protocol Profile for a LAN connected server pool?

On the serverside, the BIG-IP is generally the TCP receiver. That, combined with LAN characteristics, make it matter much, much less what profile you choose. That said, I would recommend you run tcp-lan-optimized in LAN scenarios.

 

Varma_Dantuluri
Historic F5 Account
Do the recommendations in 'What you should do instead?' apply for SWG/Forward Proxy deployments as well? SWG deployments will usually have a http profile attached.
Martin_Duke
Legacy Employee
Legacy Employee
Do the recommendations in 'What you should do instead?' apply for SWG/Forward Proxy deployments as well? SWG deployments will usually have a http profile attached.

I don't see a reason that those deployments would have dramatically different path dynamics. However, TCP profiles are most important when BIG-IP is sending data over the open internet -- and in a forward proxy, in general you are receiving it. So it's not that the recommended profiles don't apply, it's that they matter less.

 

Zdenda
Cirrus
Cirrus

Hi, we have been using tcp-lan-optimized for most of our deployments. I assumed this is good choice among all profiles. Do you think it is worth to change it to any of profiles you recommended?

 

rrrrrrrrrrrrrr1
Nimbostratus
Nimbostratus

Serious performance problems using tcp-mobile-optimized profile

 

I have special hardware tokens containing client certificates (client ssl profile require setting). When using tcp-mobile-optimized profile (client) a first connection is done only in 30 seconds. When using protocol profile (client) standard = tcp: the connection is done instead within approx. 10 seconds When using protocol profile (client) = tcp-lan-optimized: the connection is done instead within approx. 8 seconds When using protocol profile (client) = tcp-legacy: approx 12 seconds

 

Martin_Duke
Legacy Employee
Legacy Employee

Hi, we have been using tcp-lan-optimized for most of our deployments. I assumed this is good choice among all profiles. Do you think it is worth to change it to any of profiles you recommended?

 

If your environment is more like a LAN that other link types, then no.

 

Zdenda
Cirrus
Cirrus

Martin Duke: not really, it is mixed. Some services published to internet, some services published to customers via private links, mpls etc..

 

Martin_Duke
Legacy Employee
Legacy Employee

In my opinion, the best current profile we have for general internet use (with many different link types) is mptcp-mobile-optimized. In 13.1 we will release some new built-in profiles that give you some better options.

 

How to test these profile on F5, is there any method or tool or just ninja TCP skill using tcpdump etc. Just want to know how people test these profile and decide base on what matrix?

 

Martin_Duke
Legacy Employee
Legacy Employee

I would suggest TCP Analytics to do this; set up one virtual with one profile, one with another, and compare.

 

https://devcentral.f5.com/articles/introducing-tcp-analytics-20425

 

Martin, while you reply then I have one more question, we have many API server behind F5 and our client all over the world they making API calls to our server and API request is very small, in short out application isn't browsable. What profile I should use for short live calls? Currently we are using default TCP profile, after reading your post I am curious, so should I change to WAN/LAN?

 

Martin_Duke
Legacy Employee
Legacy Employee

I'm not sure I understand all of your question. If the data flows are quite small, then a lot of the througput constraints don't really matter. A chatty, low-volume application is probably fine with the default profile, but with Nagle and delayed ack off.

 

Thanks Martin, In short our clients making small API calls to Web application to access token so per connection flow is very small few Kbytes per request and we are terminating SSL on F5. Should i disable Nagle/Delayed ACK on both direction Client/Server side?

 

razor85_180132
Nimbostratus
Nimbostratus

Please note that suggested mptcp-mobile-optimized profile has Nagle's Algorithm enabled. This option has negative imapct on http traffic. I observe decreased service performance after switching to non-default profile. Be careful with those changes!

 

MarS_269999
Nimbostratus
Nimbostratus

Why not make a TCP profile per services publishing. Example is tcp-ms-share-point. In my opinion is this the best option. For example, I have a share point with large file transfer. Without F5 the download to the client is 60Mbps and through F5 is max 40Mbps. This is really frustrating to tune. In my case on 13.1.0.3 is the best option tcp-lan-optimized with some tuning. I have tried mptcp-mobile-optimized and in my case is really not an option. The worst thing is that a costumer won't switch to F5 ADC as work better directly on MS.

 

Hank_Moody_3649
Nimbostratus
Nimbostratus

Hey MarS "In my case on 13.1.0.3 is the best option tcp-lan-optimized with some tuning." Could u tell me how you explicit tuned the profile? We have slow performance problem from external access to our new exchange 2016 iapp

 

MarS_269999
Nimbostratus
Nimbostratus

With 2 day session capturing and analyzing tcp profile I had solved the problem using f5-tcp-progressive tcp profile for client and server. Developers team had tested and agree that it works almost 1:1.

 

Version history
Last update:
‎14-Oct-2015 15:34
Updated by:
Contributors