This article describes how to configure, verify, and troubleshoot TCP window Scaling on a NetScaler appliance.
A TCP window is an amount of outstanding data, the data not acknowledged by the recipient, which sender can send on a connection before receiving an acknowledgment from the receiver about the receipt of some of the data. The primary reason for the window is to manage traffic congestion.
For example, if a pair of hosts communicates over a TCP connection that has a TCP window size of 64 kilobytes (KB), the sender can only send 64 KB of data. After sending 64 KB of data, the sender must stop and wait for an acknowledgment from the receiver about the receipt of some or entire data. If the receiver acknowledges that the entire data is received, the sender is free to send another 64 KB of data. If the sender receives an acknowledgment from the receiver that only first 32 KB of data is received, then the sender can only send another 32 KB of data because the sender cannot have unacknowledged outstanding data of more than 64 KB.The receiver might not have received the remaining 32 KB of data because of any of the following reasons:
The remaining 32 KB of data is still in transit.
The TCP window size is controlled by the window size parameter in the TCP header, which is 16 bits long. This size limits the ability of the sender to advertise the window size to 65536, which is 2^16. The following table demonstrates the TCP header format that contains the window size as well as other TCP protocol specifications, as defined in the RFC 793:
Source Port (16 bits) | Destination Port (16 bits) | |||
Sequence Number (32 bits) | ||||
Acknowledgment Number (32 bits) | ||||
Len (4 bits) | Unused (6 bits) | Flags (6 bits) | Window Size (16 bits) | |
Checksum (16 bits) | Urgent Pointer (16 bits) | |||
Type (8 bits) | Length (8 bits) | Data (16 bits) |
You can use a tcpdump network trace to determine the window size. The following is an example of a typical network trace displayed by expanding the TCP stack in the Wireshark application.
Ethernet II, Src: HewlettP_33:2e:a1 (00:11:0a:33:2e:a1), Dst: Iwill_09:d4:86 (00:d0:68:09:d4:86) Internet Protocol, Src: 10.3.250.11 (10.3.250.11), Dst: 10.3.250.16 (10.3.250.16) Transmission Control Protocol, Src Port: 3215 (3215), Dst Port: http (80), Seq: 280837115, Len: 0 Source port: 3215 (3215) Destination port: http (80) Sequence number: 280837115 Header length: 32 bytes Flags: 0x02 (SYN) Window size: 64512 Checksum: 0x115e [correct] Options: (12 bytes)Note: In the preceding example, the window size advertised by the sender is in bold face for your reference.
The TCP window Scale extension expands the definition of the TCP window to 32 bits by using a scale factor to carry this 32 bit value in the 16 bit window field of the TCP header, SEG.WND as defined in the RFC 793. The scale factor is carried in a new TCP option, window Scale. This option is only sent in a SYN segment, a segment with the SYN bit on, and the SYN-ACK segment, a segment with the SYN and ACK bits on. Therefore, the window scale is fixed in each direction when a connection is opened. This extension is defined in the RFC 1323.
You can verify the window scale by using a tcpdump network trace. The following is an example of a typical network trace displayed by expanding the TCP stack for the SYN and SYN-ACK packets in the Wireshark application.
Ethernet II, Src: Iwill_0c:a2:23 (00:d0:68:0c:a2:23), Dst: VRID_ff (00:00:5e:00:01:ff) Internet Protocol, Src: 10.128.116.22 (10.128.116.22), Dst: 10.119.159.152 (10.119.159.152) Transmission Control Protocol, Src Port: 22157 (22157), Dst Port: http (80), Seq: 2105340, Len: 0 Source port: 22157 (22157) Destination port: http (80) Sequence number: 2106340 Header length: 32 bytes Flags: 0x02 (SYN) Window size: 62645 Checksum: 0x0000 [Checksum Offloaded] Options: (12 bytes) Maximum segment size: 1460 bytes NOP Window scale: 3 (multiply by 8) NOP NOP SACK permitted
You can use the following formula to calculate the actual Window size used by the sender:
Actual window size = (<Window_Size>) * (2 ^ <Window_Scale>)
For example, the following is the calculation for the actual window size in the preceding sample:
Actual window size = (62645) * (2 ^ 3)
= 501106
Note: The window size sent, even if a Scale factor is set, is never greater than 65535. The window scale calculation is actually done at each host.
nsroot> set ns tcpparam -WS ENABLED -WSVal 4
Done
-WS is used to ENABLE/DISABLE the feature.
-WSVal is used to set the scale value.
add ns tcpProfile <name> [-WS ( ENABLED | DISABLED )] [-WSVal <positive_integer>]
To verify the settings of the TCP Window scaling and other TCP parameters on a NetScaler appliance, run the following command from the command line interface of the appliance:
nsroot> show ns tcpparam
TCP Parameters Window Scaling status : ENABLED Window Scaling factor : 4 SACK status : DISABLED MaxBurst setting : 6 MSS Initial cwnd setting : 4 MSS TCP Receive Buffer : 8190 bytes
The following table lists the scale factors you can use and the respective Window scale size:
Scale Factor |
Scale Value |
Initial Window |
Window Scaled |
0 |
1 |
65535 or less |
65535 or less |
1 |
2 |
65535 |
131,070 |
2 |
4 |
65535 |
262,140 |
3 |
8 |
65535 |
524,280 |
4 |
16 |
65535 |
1,048,560 |
5 |
32 |
65535 |
2,097,120 |
6 |
64 |
65535 |
4,194,240 |
7 |
128 |
65535 |
8,388,480 |
8 |
256 |
65535 |
16,776,960 |
9 |
512 |
65535 |
33,553,920 |
10 |
1024 |
65535 |
67,107,840 |
11 |
2048 |
65535 |
134,215,680 |
12 |
4096 |
65535 |
268,431,360 |
13 |
8192 |
65535 |
536,862,720 |
14 |
16384 |
65535 |
1,073,725,440 |
Consider the following points when troubleshooting TCP Window Scaling on a NetScaler appliance:
Refer to the NetScaler product documentation suite for more information about window scaling on the NetScaler appliance.
Note: The Citrix NetScaler product documentation can be accessed from the Citrix Knowledge Center by NetScaler customers who are logged on and have valid NetScaler maintenance agreements.
For more information about the TCP window scaling, refer to the Wikipedia Web site.