In Depth Understanding of Your Appliance > Configuration Reference Guide > Optimization > Configure TCP Acceleration

Configure TCP Acceleration

TCP Acceleration is the heart of Exinda's application acceleration technology. All accelerated connections pass through TCP Acceleration. In order to accelerate traffic over the WAN, Exinda transparently proxies TCP connections at each end. Both the client and server think they have established a connection with each other; however, they have connected with their local Exinda devices.

In addition to facilitating other acceleration technologies like WAN Memory and SMB acceleration, TCP acceleration also provides performance improvements over and above regular TCP, while being fully compliant with TCP.

You can configure various settings for TCP acceleration.

Acceleration occurs between two Exinda appliances. The appliances can discover other appliances on the network that they can accelerate with. You can configure whether your appliance will attempt to discover other appliances and which IP address your appliance will use when other appliances discover your appliance.
TCP acceleration and auto-discovery require the use of custom TCP options. If other equipment is stripping the required TCP option from the TCP headers, you can specify that the TCP accelerated traffic must tunnel to avoid the options being stripped. Once a connection is setup via the protocol tunnel, subsequent connections can use the protocol connection and avoid the 3-way TCP handshake, which will reduce the number of TCP connections traversing the WAN and reduces the TCP connection setup time.
Also TCP option 30 which historically has been used to indicate Exinda acceleration, has been assigned to indicate multi-path TCP. Exinda now uses both option 30 and option 230 to indicate Exinda acceleration. You can specify which option code should be used in acceleration. Your choice will depend on the Exinda appliance version you are using and whether you are seeing multi-path TCP traffic in your network. Also you can indicate not to accelerate traffic (bypass acceleration) when traffic is using multi-path TCP.
Throughput is limited by two windows: the TCP receive window size and the congestion control window. Setting the appropriate sizes for these windows can ensure efficient use of the available bandwidth:

Windows scaling increases the TCP window size, which allows more data to be in-flight before TCP requires acknowledgments. This means higher throughput can be achieved on WAN links with higher levels of latency.
Selectable congestion control algorithms can be chosen to match the WAN environment. For instance, for high speed high latency links, High Speed TCP should be used. For Satellite links, or other high-latency links, TCP Hybla should be used. This allows for better TCP performance over different WAN technologies.
Adaptive Initial Congestion Window allows automatic adjustment of the initial window size depending on the connectivity properties of the WAN link between the Exinda appliances.
Slow Start with Congestion Avoidance is used to reset the send window size temporarily to avoid congestion.

TCP keep-alive signals prevent the link between accelerated appliances from being broken. You can set whether to use keep-alives and how frequently to send the keep-alive signals.
When accelerating traffic in a backhauled setting, the dual-bridge bypass setting will ensure that acceleration processing happens on only one bridge so that the traffic is not re-accelerated. This option, by default, is disabled.
When you know that a particular Exinda is always at the end of an acceleration chain, you can indicate that it is the end and therefore should not pass through option 30 packets. This is useful when the traffic is transported to a server or firewall that does not know how to handle option 30 packets or when the traffic is forwarded to the Internet. Note that you should not use this setting if the Exinda appliance is also an Exinda in the middle in some scenarios.

Furthermore, TCP acceleration also provides performance improvements without requiring configuration:

Delayed and Selective Acknowledgments are used to acknowledge the receipt of packets in batches, instead of acknowledging every single packet. This reduces the amount of return data on the wire.
Explicit Congestion Notification (ECN) allows end-to-end (between the Exinda appliances) notification of network congestion without dropping packets. Traditionally, TCP/IP networks signal congestion by dropping packets. When ECN is enabled, an ECN-aware router may set a mark in the IP header instead of dropping a packet in order to signal impending congestion.

Use the form below to configure various TCP Acceleration settings.

How do I use the settings?

Appliance Auto-Discovery – Allows the appliance to discover other Exinda appliances in its community.

When enabled, the Exinda appliance attempts to automatically discover other Exinda appliances on the network when making acceleration. Exinda appliances do this by injecting TCP option 30 into any TCP-SYN packets that the Exinda appliance is attempting to accelerate. If unknown TCP options are removed or blocked by other equipment in your network (e.g., VPN terminators, firewalls, IPS/IDS systems, etc.) then auto-discover may not work or traffic may be blocked.
When disabled, or if TCP option 30 is stripped or blocked by other equipment on your network, you will need to manually specify the location of another Exinda appliance in your network on the Configuration > System > Optimization > Community page.

Appliance Auto-Discovery IP Address – Allows you to set the IP address that identifies this appliance when other appliances are trying to discover their appliance community. Usually this is the management IP address or the IP address to which the default route is associated.

auto – The appliance auto-detects its own IP address.
<IP address> - Select an IP address from the list.

Transport Type – Allows you to specify whether acceleration should be fully transparent or tunnelled. Exinda acceleration makes use of TCP option 30 and/or TCP option 230. This setting makes the use of these options transparent or hidden.

Transparent TCP – Ensures Exinda's Application Acceleration is fully transparent. Source and destination IP addresses and port numbers are maintained on all accelerated connections, so any equipment in between two accelerating Exinda appliances can still see correct IP and TCP headers.
Protocol Tunnel – When equipment in between two accelerating Exinda appliances will strip the TCP options, you will need to use the Protocol Tunnel transport type so that other equipment cannot strip these required option codes.

Window Scaling Factor – Specifies how large the TCP receive window can be, according to the formula: TCP Window Size kB = 64 kB x 2 ^ Window Scaling Factor. The scaling factor ranges between 0 and 14, meaning that the receive window can be between 64 kB and 1 GB. The TCP window scaling factor is needed for efficient transfer of data when the bandwidth-delay product is greater than 64kB. The default scaling factor is 5 resulting in a window size of 2MB. Larger window sizes result in more potential memory usage. However, the window size may need to be increased in high-bandwidth, high-latency environments to ensure the bandwidth is fully utilized.

Congestion Control – Indicates which congestion control algorithm should be used. The most common congestion control algorithms are listed together with their intended usage. Set this according to the type of WAN the Exinda appliances are deployed into. This setting only affects outbound traffic to the WAN, so the same setting should be applied to all Exinda appliances on the WAN.

TCP Keep-Alive Enabled – Enables the sending of keep-alive packets on the WAN.

TCP Keep-Alive Timeout – Specifies the amount of time, in seconds, that a connection may be idle before sending keep-alive packets is enabled. Keep-alive packets are sent once per minute until either a response is received, or 5 minutes passes. If five minutes passes without a response the connection is terminated.

Dual Bridge Bypass – Specifies whether acceleration should be handled on a single bridge or multiple bridges when traffic is passing through an Exinda appliance multiple times.

Enabled – All acceleration processing is performed on one bridge only. This is desirable for accelerated backhauled traffic.
Disabled – Acceleration processing is performed on whatever bridge it arrives on. This is desirable for asymmetric routing or link aggregation.

To learn more about this feature, see Dual Bridge Bypass.

Acceleration TCP Options Mode – Specifies which option code to use in tagging accelerated packets.Historically, Exinda appliances used TCP option 30, however, TCP option 30 has be assigned to indicate multi-path TCP. Exinda started using option 230 in v7.0.

30+230: Send 230 where possible, 30 when unsure, accept both (default) – The system will respond with whatever the remote used. If both options 230 and 30 are available, option 230 will be used. This is the best choice when some of your appliances are v7.0 and later and some are v6.x and earlier. This is a compatibility mode.
230: Send and accept options 230 only – Only option 230 will be used. Packets with option 30 will not be looked at. Use this when all your appliances are v7.0 and later.
30: Send and accept options 30 only – Only option 30 will be used. Packets with option 230 will not be looked at. Use this when all your appliances are earlier than v7.0.
230-compat: Send options 230, accept incoming options 30 – Always sends using option 230 and uses compatibility mode for receiving packets, that is, it will handle receiving both option 230 and option 30.
30-compat: Send options 30, accept incoming options 230 – Always sends using option 30 and uses compatibility mode for receiving packets, that is, it will handle receiving both option 230 and option 30.

Multi-Path TCP (MPTCP) Acceleration Bypass – Specifies whether to attempt acceleration if the traffic is identified as multi-path TCP and falls into an acceleration policy.

When enabled and the traffic falls into an acceleration policy, multi-path TCP flows are not accelerated. The multi-path TCP options are not stripped and the flows will continue to work in a multi-path TCP fashion.
When disabled and the traffic falls into an acceleration policy, the multi-path TCP options will be stripped and acceleration will be attempted.
When the traffic does not fall into an acceleration policy (regardless of this setting), the multi-path TCP options with not be stripped and the flows will work in a multi-path TCP fashion.

End Acceleration (no acceleration on the LAN) – Forces acceleration to end on this appliance.

When enabled, any incoming acceleration connections on the WAN will be terminated at this appliance and no attempt will be made to find another appliance on the LAN interface. This has no effect on accelerated connections arriving on the LAN.
Consider traffic passing from the client to the server through two accelerated Exinda appliances:
Client -> (LAN-side) Exinda (WAN-side) -> WAN -> (WAN-side) Exinda (LAN-side) -> Server
Normally, the server side Exinda would send out an option 30 packet to the server. However, if the server does not know how to handle with an option 30, it will return a SYN/ACK without an option 30. Enabling this setting allows the server-side Exinda to know that it is the last appliance in the chain and so it will not send out a SYN with option 30 and it terminates the acceleration connection.
In addition to stopping this appliance from sending option 30 packets to servers that are known to not handle them, it also reduces the timeouts that happen with protocol 139 when attempting to accelerate past the last appliance. It allows servers/firewalls that refuse options to work. It prevents sending random options out to the Internet, which is the case in an accelerated backhauled traffic environment with only a single pair of Exinda appliances. If you have a hub-and-spoke topology then you will not want to enable this setting.