Some TCP connections, especially long-distance ones, often experience high latency and has a negative impact on the user experience. Cato Networks’ TCP acceleration feature accelerates the TCP connections over the WAN and improves the network efficiency and speed for TCP traffic.

This article explains how Cato implements TCP acceleration and lists some best practices to optimize TCP acceleration for specific applications that are based on TCP traffic.

Explaining TCP Acceleration

Cato accomplishes TCP acceleration by designating the Cato PoPs to act as an intermediate proxy server between the client and the destination server. The proxy eliminates a long-distance connection and instead splits it into three short ones. The advantage is that instead of maintaining a long-distance connection, the Socket maintains a short connection to the closest PoP. The traffic between the PoPs is transferred over the Cato Cloud private backbone that guarantees the cloud speed and low latency. The PoP that is the closest to the destination, sends the traffic to the server.

If there is packet loss, the PoPs are responsible for retransmitting packets and this allows a quick reaction and reduces the response time. This technique improves TCP performance and reduces the recovery time if a tunnel disconnects. Each short connection has a shorter round-trip time (RTT) per packet as compared to one long-distance connection. The short connections improve performance and guarantees a faster data delivery to the destination. A long-distance connection with a high RTT means that packets are traveling for a longer time until they reach the destination. The longer travel time and slow connections can create a poor user experience.

The following diagram shows a connection from client to server where PoP A and PoP B act as proxy servers:

The proxy splits the long-distance connection between the client and the server to three short connections:

1. First connection is from the Socket to PoP A.
2. Second connection is from PoP A to PoP B, over the Cato Cloud.
3. The third connection is from PoP B to the destination server.

Each PoP maintain its own TCP stack and reduces TCP packets retransmissions of the entire window in the case of packet loss. When the PoP receives SYN messages from the client, it quickly returns ACK responses to the client, instead of waiting for the response from the server. Meanwhile, the Socket continues to send the TCP traffic which makes the connection faster. The PoP allocates a larger TCP stack window size according to the following formula: window size = RTT * bandwidth. For example, for connections with an RTT of 200MS and bandwidth of 20MBS, the TCP window size is 4 MB (0.2 Sec * 20 MB).

Note: TCP acceleration is not supported for Alternative-WAN and Off-Cloud transports.

Recovering from PoP Disconnection

In the case that the tunnel from the Socket to the PoP disconnects, the Socket then tries to reconnect to the same PoP. If the Socket manage to reconnect, the connection is recovered since the PoP keeps the tunnel state. In the case that the Socket can’t connect to the same PoP, and TCP acceleration is enabled for a network rule, the state of existing connections is lost. Since the PoP acts as the TCP proxy server, when the Socket loses connectivity to the PoP, the state of the connection is lost, and the client must initiate a new connection.Therefore, we recommend enabling TCP proxy for applications that can survive momentary disconnections such as web applications and file sharing.

Egressing Traffic with TCP Acceleration

When egressing traffic in a network rule, the PoPs act as proxy servers for the connection and Cato automatically activates TCP acceleration. You can’t disable TCP acceleration for egress rules in the Cato Management Application. The following screenshot shows an egress network rule where the Active TCP Acceleration option is greyed out (Network > Network Rules > Edit Rule).

For more about egress rules, see Best Practices for Egressing Traffic In a Network Rule.

Enabling TLS Inspection

The TLS inspection feature decrypts HTTPS traffic for security features such as Anti-Malware and IPS. This feature uses the PoPs as proxy servers to inspect the traffic for malicious files and threats. The TLS inspection is for applications that are based on HTTP traffic and TCP acceleration is recommended for these applications. Therefore, it is important to know that when you enable TLS Inspection for your account, Cato activates TCP acceleration for all TLS traffic. For more about TLS inspection, see Configuring the TLS Inspection Policy for the Account.

Best Practices for TCP Acceleration

This section describes best practices for when to enable TCP acceleration for specific types of applications.

Enabling TCP Acceleration for Web Applications

Commonly, web applications are clientless and use a web browser to connect to a server. Cato’s TCP acceleration engine significantly improves the performance of this traffic. We recommend that you enable TCP acceleration for network rules with web applications.

Enabling TCP Acceleration for File Sharing Applications

Files sharing applications, such as SMB, can suffer from network latency or retransmissions in the case of packet loss. If you use files sharing between computers in your network (ie. SMB protocol for resources sharing), Cato’s TCP acceleration can significantly improve the files transfer speed. We recommend that you enable the TCP acceleration for these applications’ network rules.

Disabling TCP Acceleration for Sensitive Applications

There are some applications that are sensitive to network disconnections and it is difficult for them to recover after a disconnect. These applications are commonly desktop legacy applications in a client-server architecture. After a disconnection, they force the client to initiate a new connection and then lose the connection state. For example, for Citrix clients that already use an optimized protocol, we recommend that you disable the TCP acceleration for network rule with this traffic.

We also recommend that you disable TCP acceleration for VoIP applications, when SIP is over TCP. When TCP acceleration is enabled, the PoP acts as a TCP proxy for the traffic which can impact the connection recovery capabilities. When the connection to the PoP is down, the PoP can’t maintain the connection state of the client flows and the call is dropped. In this situation, the phone is unable to reconnect the client and it must establish a new connection and SIP registration. Disabling TCP acceleration for VoIP traffic minimizes the chances of dropped calls for end users.

Fine Tuning TCP Acceleration for Windows OS

This section discusses how to optimize the TCP setting for Windows computers to improve the TCP acceleration for your network rules.

Enabling TCP Window Scaling Option

Some Windows operating systems are configured to use a default window size of 64KB. This window size is limited and can cause performance issues and latency. Cato PoPs allocate a TCP stack that is larger than the default window size for more efficient data transfer. Therefore, we highly recommend that you enable the TCP window scaling option in your Windows computers.

Note: Usually the TCP window scaling option is enabled by default.

Enabling TCP Timestamp Option

The default setting for Windows operating systems doesn’t support the TCP timestamp option. Enable the TCP timestamp option to improve the packets RTT measurements and help to identify packet loss. This option also assists the TCP stack to adjust the retransmission timer in case of packet loss. We recommend enabling the TCP timestamp in your Windows computers.