Community Articles

CP Parameter Tuning and Window Scaling

Bill Alderson, Technology Consulting Officer, NetQoS, Inc.

People are buying LFPs (long fat pipes) these days. An LFP is a wide area link higher than T1/E1 (1.5 to 2 megabits) across a long distance. Some use LFPs for general LAN interconnection (thousands of nodes) and others use them for special purposes such as a pair of nodes doing database replication or back up. Whether a pair of nodes will consume the entire bandwidth or a group of nodes will collectively consume the bandwidth matters. There are issues associated with which nodes need TCP Window Scaling options and which do not.

TCP is a byte-oriented, sliding-window protocol and different from its proprietary contemporaries of IPX/SPX, LLC2 (SNA LAN Transport), and DECnet. These protocols offer a window of blocks or segments toward which one sends data. TCP offers a window of bytes into which one sends. TCP is sent in bytes from a SEQuence number at a byte count, ACKnowledged in bytes, and sent into a WINdow of bytes. It is a byte-oriented protocol as opposed to block-oriented protocol like the other protocols. Think of TCP WINdow size like your credit card spending limit of $16,000 wherein you can spend $1 in each of 16,000 transactions or $16,000 in one transaction. The number of blocks or segments of data does not matters. It is the total number of bytes sent that matters. (TCP Slow-Start and TCP MSS will be discussed in another article.)

TCP WINdow size is the advertised permissable amount of data to send before awaiting an ACKnowledgement of sent data or a new WINdow into which to send. In fact, ACKnowledgement is not what allows further sending, it is the WINdow advertised with or subsequent to ACKnowledgement that matters. Sometimes a node receives data, ACKnowledges it, but does not advertise a WINdow to the sender who must wait for a new advertised WINdow into which it can send.

As an example of transferring full speed across an LFP between two stations, let's say you have a database to replicate or a backup to accomplish across the LFP. You want to complete the transfer as fast as the least common denominator of intervening link speed allows. With that in mind, you must ensure that the receiving station has enough TCP WINdow size to allow the sending station to continue transmitting long enough for the following to happen while the sender never stops transmitting at the least common denominator of link speed:

• Data reaches the receiver
• Receiver ACKnowledges at layer 4
• Receive pulls data out of the buffer at layer 7
• Receiver increases the WINdow size at layer 4
• Receiver transmits the WINdow size back to the sender

If the above happens, the transfer speed approximates the link's LCD speed and life will be good.

To set the WINdow size high enough for this to occur, you must know two things: the LCD link speed, which could be 45,000,000 bits per second as an example, and the latency, which could be 50 milliseconds (.050 seconds). For this to work, you must be able to continue transferring data at the LCD for the entire round trip plus what it takes the recipient to ACKowledge the data and receive the data into layer 7, which opens the buffer for more data at layer 4 and allows the TCP stack to clean up its WINdow size and advertise the WINdow size back to the sender across the link latency. For this exercise, assume the WINdow size will be the link latency.

To calculate this, you must calculate the transmission for round trip latency duration as follows:

45,000,000 / 8 bits per byte = 5625000 * .05 = 281250 bytes of advertised TCP WINdow

To accomplish this, you must enable TCP Window Scaling to extend beyond the native TCP Window size of 64 * 1024 or 65535 bytes. The native TCP WINdow size is a 16-bit number, which is at a maximum 65535 decimal. To extend TCP for high performance networks, RFC 1323 allows you to scale the native 16-bit field value to multiples from 2 to 16384, which allows the WINdow size to scale to 1 GB.

Window scaling allows the native TCP WINdow to scale to support the LFPs found in more of today's networks.

When not to use window scaling

Even Texans, who like things BIG, know not to scale too big for no reason. If an organization uses high-speed links everywhere, they might not want two common nodes to consume the entire bandwidth. In this case, leaving the options in native mode WS=0 (Window Size equals zero) is the best way to throttle common traffic while nodes needing to consume the full link speed get access by using the Window Scaling Option.

Other cautions

Empowering databases and backup systems to use Window Scaling is a great idea, but limit these nodes and their functions to the appropriate times to consume bandwidth. You might not want backups to operate during certain business hours or you might find them competing for bandwidth you need for other purposes.

Just like any system parameter, judicious use and controls should apply.

Loading...