After having a huge number of questions regarding this topic of the last couple of weeks, I decided to write a blogpost about it, to clarify some of the misconceptions about this feature on NetScaler.
NOTE: TCP profiles can be found under System –> Profiles –> TCP
TCP profiles is a feature which allows us to customize TCP parameters on a NetScaler which we then can bind to a specific object. TCP profiles can be bound either globally, to a virtual server or to service (service groups). Important to note that TCP profiles can be bound to for instance at a global level, this will affect all TCP communication on the NetScaler, but we can for instance customize a TCP profile which we can bind to a virtual server, which will then override the TCP profile on the global level for that partciular virtual server.
Same goes for services, if we have a TCP profile bound globally, if we create a custom TCP profile which we then bind to a service, then it will override the global TCP settings that are defined.
So why should we customize TCP settings for different objects?
Our end-users access resources differently, for instnace on one hand we might have users using Citrix Receiver which is dependant on having a good experience wherever they are and on many different devices. On the other hand we might have mobile users working from their phones accessing resources using an app, and in most cases working wirelessly and roaming between 3G/4G and WiFi where it also often roams between access points, where you also have an high amount of packet loss.
Now in another of the puzzle are the internal resources that the NetScaler needs to talk to which are often connected to an high-speed ethernet 1GB/10GB connection, with no to little packet loss.
Think about it if you were to talk with a friend that sits right next to you, which is like internal traffic. No latency, little retransmission. On the other hand try talking to someone riding a bycicle far away, you would need to maybe repeat alot of word or sentences to that person and also you might tneed to speak slower as well to adjust and make sure that the other person receives what you are saying.
So TCP should also act differently depending on where the user is, and how their connection is. The default TCP profile on the NetScaler has not be adjusted for a long time, so it tries to communicate in the same way with internal resources and with external resources on the virtual server level, but of course it is there to ensure compability.
Another thing to remember is that there are many TCP settings that if enabled might impact the TCP performance badly as well. So when configuring TCP settings, if you are customizing on your own be sure that you test and validate TCP performance.
Now for most of us, it is alot simpler. Citrix NetScaler has pre created TCP profiles for different use cases.
Some of it, is use of features like SACK and DSACK, Nagle, MTCP and so on. Another important factor is the use of congestion algoritms and when to choose what.
This chart can be used as a guideline on which congestion algoritm to choose.
source: http://support.citrix.com/article/CTX211877
Now as an important factor
⦁ NetScaler Gateway does not have the concept of Services, hence a TCP profile can only be bound to the Virtual Server. All other internal traffic will be using the default TCP profile.
⦁ Virtual Servers like Content Switching, Load balancing and so on, can have its own TCP profile attached to it. For instance if we have a virtual server that is used for serving mobile users content I would consider looking into using another congestion algoritm, and use of MTCP is the devices/application supports it
⦁ All services and service groups which communicate with internal resources can also have their own TCP profile, which is most cases nstcp_default_tcp_lan can be used for internal communication.
So hopefully you got a better understanding of TCP profiles 