TCP optimization
TCP使用以下优化技术和congestion control strategies (or algorithms) to avoid network congestion in data transmission.
Congestion Control Strategies
The TCP has long been used to establish and manage Internet connections, handle transmission errors, and smoothly connect web applications with client devices. But network traffic has become more difficult to control, because packet loss does not depend only on the congestion in the network, and congestion does not necessarily cause packet loss. Therefore, to measure congestion, a TCP algorithm should focus on both packet loss and bandwidth.
Proportional Rate Recovery (PRR) algorithm
TCP Fast Recovery mechanisms reduce web latency caused by packet losses. The new Proportional Rate Recovery (PRR) algorithm is a fast recovery algorithm that evaluates TCP data during a loss recovery. It is patterned after Rate-Halving, by using the fraction that is appropriate for the target window chosen by the congestion control algorithm. It minimizes window adjustment, and the actual window size at the end of recovery is close to the Slow-Start threshold (ssthresh).
TCP Fast Open (TFO)
TCP Fast Open (TFO) is a TCP mechanism that enables speedy and safe data exchange between a client and a server during TCP’s initial handshake. This feature is available as a TCP option in the TCP profile bound to a virtual server of a Citrix ADC appliance. TFO uses a TCP Fast Open Cookie (a security cookie) that the Citrix ADC appliance generates to validate and authenticate the client initiating a TFO connection to the virtual server. By using this TFO mechanism, you can reduce an application’s network latency by the time required for one full round trip, which significantly reduces the delay experienced in short TCP transfers.
How TFO works
When a client tries to establish a TFO connection, it includes a TCP Fast Open Cookie with the initial SYN segment to authenticate itself. If authentication is successful, the virtual server on the Citrix ADC appliance can include data in the SYN-ACK segment even though it has not received the final ACK segment of the three-way handshake. This saves up to one full round-trip compared to a normal TCP connection, which requires a three-way handshake before any data can be exchanged.
A client and a back-end server perform the following steps to establish a TFO connection and exchange data securely during the initial TCP handshake.
- If the client does not have a TCP Fast Open Cookie to authenticate itself, it sends a Fast Open Cookie request in the SYN packet to the virtual server on the Citrix ADC appliance.
- If the TFO option is enabled in the TCP profile bound to the virtual server, the appliance generates a cookie (by encrypting the client’s IP address under a secret key) and responds to the client with an SYN-ACK that includes the generated Fast Open Cookie in a TCP option field.
- The client caches the cookie for future TFO connections to the same virtual server on the appliance.
- When the client tries to establish a TFO connection to the same virtual server, it sends SYN that includes the cached Fast Open Cookie (as a TCP option) along with HTTP data.
- The Citrix ADC appliance validates the cookie, and if the authentication is successful, the server accepts the data in the SYN packet and acknowledges the event with an SYN-ACK, TFO Cookie, and HTTP Response.
Note:
If the client authentication fails, the server drops the data and acknowledges the event only with a SYN indicating a session timeout.
- On the server side, if the TFO option is enabled in a TCP profile bound to a service, the Citrix ADC appliance determines whether the TCP Fast Open Cookie is present in the service to which it is trying to connect.
- If the TCP Fast Open Cookie is not present, the appliance sends a cookie request in the SYN packet.
- When the back-end server sends the Cookie, the appliance stores the cookie in the server information cache.
- If the appliance already has a cookie for the given destination IP pair, it replaces the old cookie with the new one.
- If the cookie is available in the server information cache when the virtual server tries to reconnect to the same back-end server by using the same SNIP address, the appliance combines the data in SYN packet with the cookie and sends it to the back-end server.
- The back-end server acknowledges the event with both data and a SYN.
Note:If the server acknowledges the event with only a SYN segment, the Citrix ADC appliance immediately resends the data packet after removing the SYN segment and the TCP options from the original packet.
Configuring TCP fast open
To use the TCP Fast Open (TFO) feature, enable the TCP Fast Open option in the relevant TCP profile and set the TFO Cookie Timeout parameter to a value that suits the security requirement for that profile.
Enable or disable TFO by using the CLI
At the command prompt, type one of the following commands to enable or disable TFO in a new or existing profile.
Note:The default value is DISABLED.
add tcpprofile - tcpFastOpen ENABLED | DISABLED set tcpprofile - tcpFastOpen ENABLED | DISABLED unset tcpprofile - tcpFastOpen Examples add tcpprofile Profile1 – tcpFastOpen Set tcpprofile Profile1 – tcpFastOpen Enabled unset tcpprofile Profile1 – tcpFastOpen
To set TCP Fast Open cookie timeout value by using the command line interface
At the command prompt, type:
set tcpparam –tcpfastOpenCookieTimeout Example set tcpprofile –tcpfastOpenCookieTimeout 30secs
对configure the TCP Fast Open by using the GUI
- Navigate toConfiguration>System>Profiles> and then clickEditto modify a TCP profile.
- On theConfigure TCP Profilepage, select theTCP Fast Opencheck box.
- ClickOKand thenDone.
To Configure the TCP Fast Cookie timeout value by using the GUI
Navigate toConfiguration>System>Settings>Change TCP Parametersand thenConfigure TCP Parameterspage to set the TCP Fast Open Cookie timeout value.
TCP HyStart
A new TCP profile parameter, HyStart, enables the HyStart algorithm, which is a slow-start algorithm that dynamically determines a safe point at which to terminate (ssthresh). It enables a transition to congestion avoidance without heavy packet losses. This new parameter is disabled by default.
If congestion is detected, HyStart enters a congestion avoidance phase. Enabling it gives you better throughput in high-speed networks with high packet loss. This algorithm helps maintain close to maximum bandwidth while processing transactions. It can therefore improve throughput.
Configuring TCP HyStart
To use the HyStart feature, enable the Cubic HyStart option in the relevant TCP profile.
对configure HyStart by using the command line interface (CLI)
At the command prompt, type one of the following commands to enable or disable HyStart in a new or existing TCP profile.
add tcpprofile -hystart ENABLED set tcpprofile -hystart ENABLED unset tcprofile -hystart
Examples:
add tcpprofile profile1 -hystart ENABLED set tcpprofile profile1 -hystart ENABLED unset tcprofile profile1 -hystart
对configure HyStart support by using the GUI
- Navigate toConfiguration>System>Profiles> and clickEditto modify a TCP profile.
- On theConfigure TCP Profilepage, select theCubic Hystartcheck box.
- ClickOKand thenDone.
TCP burst rate control
It is observed that TCP control mechanisms can lead to a bursty traffic flow on high speed mobile networks with a negative impact on the overall network efficiency. Due to mobile network conditions such as congestion or Layer-2 retransmission of data, TCP acknowledgments arrive clumped at the sender triggering a burst of transmission. These groups of consecutive packets sent with a short inter-packet gap it is called TCP packet burst. To overcome traffic burst, the Citrix ADC appliance uses a TCP Burst Rate Control technique. This technique evenly spaces data into the network for an entire round-trip-time so that the data is not sent into a burst. By using this burst rate control technique, you can achieve better throughput and lower packet drop rates.
How TCP burst rate control works
In a Citrix ADC appliance, this technique evenly spreads the transmission of a packet across the entire duration of the round-trip-time (RTT). This is achieved by using a TCP stack and network packet scheduler that identifies the various network conditions to output packets for ongoing TCP sessions to reduce the bursts.
At the sender, instead of transmitting packets immediately upon receipt of an acknowledgment, the sender can delay transmitting packets to spread them out at the rate defined by scheduler (Dynamic configuration) or by the TCP profile (Fixed configuration).
Configuring TCP burst rate control
To use the TCP Burst Rate Control option in the relevant TCP profile and set the burst rate control parameters.
To set TCP burst rate control by using the command line
At the command prompt, set one of the following TCP Burst Rate Control commands are configured in a new or existing profile.
Note: The default value is DISABLED.
add tcpprofile -burstRateControl Disabled | Dynamic | Fixed set tcpprofile -burstRateControl Disabled | Dynamic | Fixed unset tcpprofile -burstRateControl Disabled | Dynamic | Fixed
Where,
Disabled – If the Burst rate control is disabled, then a Citrix ADC appliance does not perform burst management other than the maxBurst setting.
Fixed – If the TCP burst rate control is Fixed, the appliance uses the TCP Connection Payload Send Rate value mentioned in the TCP Profile.
Dynamic – If the Burst Rate Control is “Dynamic” the connection is being regulated based on various network conditions to reduce TCP bursts. This mode works only when the TCP connection is in ENDPOINT mode. When Dynamic Burst Rate control is enabled the maxBurst parameter of the TCP profile is not in effect.
add tcpProfile profile1 -burstRateControl Disabled set tcpProfile profile1 -burstRateControl Dynamic unset tcpProfile profile1 -burstRateControl Fixed
To set TCP Burst Rate Control parameters by using the command line interface
At the command prompt, type:
设置ns tcpprofile nstcp_default_profile -burstRateControl –tcprate -rateqmax T1300-10-2> show ns tcpprofile nstcp_default_profile Name: nstcp_default_profile Window Scaling status: ENABLED Window Scaling factor: 8 SACK status: ENABLED MSS: 1460 MaxBurst setting: 30 MSS Initial cwnd setting: 16 MSS TCP Delayed-ACK Timer: 100 millisec Nagle's Algorithm: DISABLED Maximum out-of-order packets to queue: 15000 Immediate ACK on PUSH packet: ENABLED Maximum packets per MSS: 0 Maximum packets per retransmission: 1 TCP minimum RTO in millisec: 1000 TCP Slow start increment: 1 TCP Buffer Size: 8000000 bytes TCP Send Buffer Size: 8000000 bytes TCP Syncookie: ENABLED Update Last activity on KA Probes: ENABLED TCP flavor: BIC TCP Dynamic Receive Buffering: DISABLED Keep-alive probes: ENABLED Connection idle time before starting keep-alive probes: 900 seconds Keep-alive probe interval: 75 seconds Maximum keep-alive probes to be missed before dropping connection: 3 Establishing Client Connection: AUTOMATIC TCP Segmentation Offload: AUTOMATIC TCP Timestamp Option: DISABLED RST window attenuation (spoof protection): ENABLED Accept RST with last acknowledged sequence number: ENABLED SYN spoof protection: ENABLED TCP Explicit Congestion Notification: DISABLED Multipath TCP: DISABLED Multipath TCP drop data on pre-established subflow: DISABLED Multipath TCP fastopen: DISABLED Multipath TCP session timeout: 0 seconds DSACK: ENABLED ACK Aggregation: DISABLED FRTO: ENABLED TCP Max CWND : 4000000 bytes FACK: ENABLED TCP Optimization mode: ENDPOINT TCP Fastopen: DISABLED HYSTART: DISABLED TCP dupack threshold: 3 Burst Rate Control: Dynamic TCP Rate: 0 TCP Rate Maximum Queue: 0
对configure the TCP Burst Rate Control by using the GUI
- Navigate toConfiguration>System>Profiles> and then clickEditto modify a TCP profile.
- On theConfigure TCP Profilepage, selectTCP Burst Controloption from the drop-down list:
- BurstRateCntrl
- CreditBytePrms
- RateBytePerms
- RateSchedulerQ
- ClickOKand thenDone.
Protection against wrapped sequence (PAWS) algorithm
If you enable the TCP timestamp option in the default TCP profile, the Citrix ADC appliance uses the Protection Against Wrapped Sequence (PAWS) algorithm to identify and reject old packets whose sequence numbers are within the current TCP connection’s receive window because the sequence has “wrapped” (reached its maximum value and restarted from 0).
If network congestion delays a non-SYN data packet and you open a new connection before the packet arrives, sequence-number wrapping might cause the new connection to accept the packet as valid, leading to data corruption. But if the TCP timestamp option is enabled, the packet is discarded.
By default, the TCP timestamp option is disabled. If you enable it, the appliance compares the TCP timestamp (SEG.TSval) in a packet’s header with the recent timestamp (Ts.recent) value. If SEG.TSval is equal to or greater than Ts.recent, the packet is processed. Otherwise, the appliance drops the packet and sends a corrective acknowledgment.
How PAWS works
The PAWS algorithm processes all the incoming TCP packets of a synchronized connection as follows:
- If
SEG.TSval
<Ts.recent:
The incoming packet is not acceptable. PAWS sends an acknowledgment (as specified in RFC-793) and drops the packet. Note: Sending an ACK segment is necessary to retain TCP’s mechanisms for detecting and recovering from half-open connections. - If packet is outside the window: PAWS rejects the packet, as in normal TCP processing.
- If
SEG.TSval
>Ts.recent: PAWS
accepts the packet and processes it. - If
SEG.TSval
<=Last.ACK.sent
(arriving segment satisfies): PAWS copies theSEG.TSval
value toTs.recent
. - If the packet is in sequence: PAWS accepts the packet.
- If packet is not in sequence: The packet is treated as a normal in-window, out-of-sequence TCP segment. For example, it might be queued for later delivery.
- If the
Ts.recent
value is idle for more than 24 days: The validity ofTs.recent
is checked if the PAWS timestamp check fails. If the Ts.recent value is found to be invalid, the segment is accepted and thePAWS rule
updates theTs.recent
with the TSval value from the new segment.
To enable or disable TCP timestamp by using the command line interface
At the command prompt, type:
`set nstcpprofile nstcp_default_profile -TimeStamp (ENABLED | DISABLED)`
To enable or disable TCP timestamp by using the GUI
Navigate toSystem>Profile>TCP Profile, select the default TCP profile, clickEdit,选择或清除TCP timestampcheck box.
Optimization Techniques
TCP使用以下优化技术和methods for optimized flow controls.
Policy based TCP Profile Selection
Network traffic today is more diverse and bandwidth-intensive than ever before. With the increased traffic, the effect that Quality of Service (QoS) has on TCP performance is significant. To enhance QoS, you can now configure AppQoE policies with different TCP profiles for different classes of network traffic. The AppQoE policy classifies a virtual server’s traffic to associate a TCP profile optimized for a particular type of traffic, such as 3G, 4G, LAN, or WAN.
To use this feature, create a policy action for each TCP profile, associate an action with AppQoE policies, and bind the policies to the load balancing virtual servers.
For information about using subscriber attributes to perform TCP optimization, seePolicy-based TCP Profile.
Configuring policy based TCP profile selection
Configuring policy based TCP profile selection consists of the following tasks:
- Enabling AppQoE. Before configuring the TCP profile feature, you must enable the AppQoE feature.
- Adding AppQoE Action. After enabling the AppQoE feature, configure an AppQoE action with a TCP profile.
- Configuring AppQoE based TCP Profile Selection. To implement TCP profile selection for different classes of traffic, you must configure AppQoE policies with which your Citrix ADC can distinguish the connections and bind the correct AppQoE action to each policy.
- Binding AppQoE Policy to Virtual Server. Once you have configured the AppQoE policies, you must bind them to one or more load balancing, content switching, or cache redirection virtual servers.
Configuring using the command line interface
To enable AppQoE by using the command line interface
At the command prompt, type the following commands to enable the feature and verify that it is enabled:
enable ns feature appqoe
show ns feature
To bind a TCP profile while creating an AppQoE action using the command line interface
At the command prompt, type the following AppQoE action command with thetcpprofiletobind
option.
add appqoe action
show appqoe action
对configure an AppQoE policy by using the command line interface
At the command prompt, type:
add appqoe policy
To bind an AppQoE policy to load balancing, cache redirection or content switching virtual servers by using the command line interface
At the command prompt, type:
bind cs vserver cs1 -policyName
bind lb vserver
bind cr vserver
Example
add ns tcpProfile tcp1 -WS ENABLED -SACK ENABLED -WSVal 8 -nagle ENABLED -maxBurst 30 -initialCwnd 16 -oooQSize 15000 -minRTO 500 -slowStartIncr 1 -bufferSize 4194304 -flavor BIC -KA ENABLED -sendBuffsize 4194304 -rstWindowAttenuate ENABLED -spoofSynDrop ENABLED -dsack enabled -frto ENABLED -maxcwnd 4000000 -fack ENABLED -tcpmode ENDPOINT add appqoe action appact1 -priority HIGH -tcpprofile tcp1 add appqoe policy apppol1 -rule "client.ip.src.eq(10.102.71.31)" -action appact1 bind lb vserver lb2 -policyName apppol1 -priority 1 -gotoPriorityExpression END -type REQUEST bind cs vserver cs1 -policyName apppol1 -priority 1 -gotoPriorityExpression END -type REQUEST
Configuring policy based TCP profiling using the GUI
To enable AppQoE by using the GUI
- Navigate toSystem>Settings.
- In the details pane, clickConfigure Advanced Features.
- In theConfigure Advanced Featuresdialog box, select theAppQoEcheck box.
- ClickOK.
对configure AppQoE policy by using the GUI
- Navigate toApp-Expert>AppQoE>Actions.
- In the details pane, do one of the following:
- To create an action, clickAdd.
- To modify an existing action, select the action, and then clickEdit.
- In theCreate AppQoE Actionor theConfigure AppQoE Actionscreen, type or select values for the parameters. The contents of the dialog box correspond to the parameters described in “Parameters for configuring the AppQoE Action” as follows (asterisk indicates a required parameter):
- Name—name
- Action type—respondWith
- Priority—priority
- Policy Queue Depth—polqDepth
- Queue Depth—priqDepth
- DOS Action—dosAction
- ClickCreate.
To bind AppQoE policy by using the GUI
- Navigate toTraffic Management>Load Balancing>Virtual Servers, select a server and then clickEdit.
- In thePoliciessection and click (+) to bind an AppQoE policy.
- In thePoliciesslider, do the following:
- Select a policy type as AppQoE from the drop-down list.
- Select a traffic type from the drop-down list.
- In thePolicy Bindingsection, do the following:
- ClickNewto create an AppQoE policy.
- ClickExisting Policyto select an AppQoE policy from the drop-down list.
- Set the binding priority and clickBindto the policy to the virtual server.
- ClickDone.
SACK block generation
TCP performance slows down when multiple packets are lost in one window of data. In such a scenario, a Selective Acknowledgment (SACK) mechanism combined with a selective repeat retransmission policy overcomes this limitation. For every incoming out-of-order packet, you must generate a SACK block.
If the out-of-order packet fits in the reassembly queue block, insert packet info in the block, and set the complete block info as SACK-0. If an out-of-order packet does not fit into the reassembly block, send the packet as SACK-0 and repeat the earlier SACK blocks. If an out-of-order packet is a duplicate and packet info is set as SACK-0 then D-SACK the block.
Note:一群et is considered as D-SACK if it is an acknowledged packet, or an out of order packet which is already received.
Client reneging
A Citrix ADC appliance can handle client reneging during SACK based recovery.
内存checks for marking end_point on PCB are not considering total available memory
In a Citrix ADC appliance, if the memory usage threshold is set to 75 percent instead of using the total available memory, it causes new TCP connections to bypass TCP optimization.
Unnecessary retransmissions due to missing SACK blocks
In a non-endpoint mode, when you send DUPACKS, if SACK blocks are missing for few out of order packets, triggers more retransmissions from the server.
SNMP for connections bypassed optimization because of overload
The following SNMP ids have been added to a Citrix ADC appliance to track number of connections bypassed TCP optimizations due to overload.
- 1.3.6.1.4.1.5951.4.1.1.46.131 (tcpOptimizationEnabled). To track the total number of connections enabled with TCP optimization.
- 1.3.6.1.4.1.5951.4.1.1.46.132 (tcpOptimizationBypassed). To track the total number of connections bypassed TCP Optimization.
Dynamic receive buffer
To maximize TCP performance, a Citrix ADC appliance can now dynamically adjust the TCP receive buffer size.
Tail Loss Probe algorithm
A retransmission timeout (RTO) is a loss of segments at the tail end of a transaction. An RTO occurs if there are application latency issues, especially in short web transactions. To recover loss of segments at the end of a transaction, TCP uses the Tail Loss Probe (TLP) algorithm. TLP is a sender only algorithm. If a TCP connection is not receiving any acknowledgment for a certain period, TLP transmits the last unacknowledged packet (loss probe). In the event of a tail loss in original transmission, acknowledge from loss probe triggers a SACK or FACK recovery.
Configuring the Tail Loss Probe
To use the Tail Loss Probe (TLP) algorithm, you must enable the TLP option in the TCP profile and set the parameter to a value that suits the security requirement for that profile.
Enable TLP by using the command line
At the command prompt, type one of the following commands to enable or disable TLP in a new or existing profile.
Note:
The default value is DISABLED.
add tcpprofile
set tcpprofile
unset tcpprofile
Examples:
add tcpprofile nstcp_default_profile – taillossprobe
set tcpprofile nstcp_default_profile –taillossprobe Enabled
unset tcpprofile nstcp_default_profile –taillossprobe
Configure the Tail Loss Probe algorithm by using the Citrix ADC GUI
- Navigate toConfiguration>System>Profiles> and then clickEditto modify a TCP profile.
- On theConfigure TCP Profilepage, select theTail Loss Probecheck box.
- ClickOKand thenDone.
In this article
- Congestion Control Strategies
- Proportional Rate Recovery (PRR) algorithm
- TCP Fast Open (TFO)
- TCP HyStart
- TCP burst rate control
- Protection against wrapped sequence (PAWS) algorithm
- To enable or disable TCP timestamp by using the command line interface
- Optimization Techniques
- Policy based TCP Profile Selection
- To enable AppQoE by using the command line interface
- SACK block generation
- Client reneging
- 内存checks for marking end_point on PCB are not considering total available memory
- Unnecessary retransmissions due to missing SACK blocks
- SNMP for connections bypassed optimization because of overload
- Dynamic receive buffer
- Tail Loss Probe algorithm