In this tip, learn how to tweak Windows XP registry parameters through the RFC 1323 protocol, a TCP extension for high performance -- in order to tune, improve and optimize network speed and throughput. This trick will save you from having to download software, programs or worse yet -- buy additional network appliances or hardware.
Windows XP contains several registry parameters that can dramatically affect performance -- one setting deals with RFC 1323, TCP Extensions for High Performance.
The TCP window referred to in RFC 1323 is the receive window -- the buffer space that incoming TCP segments are stored in (a) unless the Push flag is set on the incoming packets and they are pushed immediately up to the application or (b) until the receiving application reaches down into the buffer to pick up its data.
During the TCP handshake process, both sides of the TCP-based connection tell each other about their receive buffer size. This is contained in the Window Size field in the TCP header. The typical value for this field would be 65,535 (it is a two byte field and this is the maximum value that can be placed in that field). This indicates that the device sending the handshake packet has 65,535 bytes of space available to store incoming data if necessary. Notice that by default XP systems will use Window Scaling if the initiating communication from a TCP peer uses the TCP Window Scale option in the TCP handshake packet. This means that if your XP box is acting as a server (responding to initiating TCP handshake packets), you'll use Window Scaling. If you are acting like a client (as in when you connect to an HTTP server or an email server, etc.), you do not use Window Scaling.
If a host runs out of buffer space during a file transfer, it must send a packet containing a Window=0 field value. The TCP peer must stop sending data until a window update packet is sent. A Window Update packet is simply an ACK packet with non-zero window size value. The flow of data may continue again once the window update process has occurred. Figure 1 shows the flow of data has stopped because a host advertises a Window Zero condition.
Click on the image for a full size view
Figure 1: The receiving host sends packets with the TCP Window Size field value set to 0 stopping the data transfer because of a lack of available receive buffer space.
The window size of 65,535 is insufficient given today's faster links, fatter pipes and larger files. The window zero condition prompted the creation of Window Scaling as defined in RFC 1323.
During the TCP handshake, if both sides add the Window Scale option in the TCP header, then window scaling is supported. BOTH sides must include a Window Scale option for either side to use the capability. The Window Scale option defines the multiplication factor to use when determining the window scale, as shown in Figure 2.
Click on the image for a full size view
Figure 2: This host advertises a Window Scale factor of 2 in its TCP handshake packet. This scale factor increases the true receive window size to 262,140 bytes.
The Window Scale value is an exponential value. For example, a Window Scale setting of 0 means multiply the Window Size field by 1 (not much help, but it does allow the other side to use window scaling). A Window Scale of 1 indicates that you should multiply the Window Size field by 2.
|Multiply Window Size Field by:||128||64||32||16||8||4||2||1|
Let's say for example, you are downloading the Open Office Suite which is over 75 megabytes (a nice big hefty file I commonly use for HTTP-based file transfer tests). If you do not have Window Scaling enabled, but you do have a decent throughput rate, your receive window could choke the file download process with only 65,535 of receive buffer space. Turning on Window Scaling and setting the scale factor to 4 would provide a receive buffer space of 262,140 bytes.
To turn on the Window Scale setting (and not the timestamp option, that I'll cover in another article), set the tcp1323opts value to 1.
Value Type: REG_DWORD -- number (flags)
Valid Range: 0, 1, 2, 3
0 (disable RFC 1323 options)
1 (window scaling enabled only)
2 (timestamps enabled only)
3 (both options enabled)
Default: No value. The default behavior is as follows: do not use the Timestamp and Window Scale options when initiating TCP connections but use them if the TCP peer that is initiating communication includes them in the SYN segment.
Description: This parameter controls the use of RFC 1323 Timestamp and Window Scale TCP options. Explicit settings for timestamps and window scaling are manipulated with flag bits. Bit 0 controls window scaling, and bit 1 controls timestamps.
Hints: Always take a baseline of network communications before making a change. This enables you to validate that your change is having a positive effect on network communications. For more information on creating network baselines, analyzing and troubleshooting TCP/IP communications, visit www.wiresharkU.com.
About the author:
Laura Chappell is the founder of Wireshark University and Protocol Analysis Institute. Ms. Chappell is a top-ranked, highly-energetic speaker and author of numerous industry titles on network communications, analysis and security. She has trained thousands of network administrators, State and Federal law enforcement officers, judicial members, engineers, technicians and developers. Ms. Chappell is a member of the High Technology Crime Investigation Association (HTCIA), active member of the FBI Infragard organization and an Associate Member of the Institute for Electrical and Electronic Engineers (IEEE) since 1989. Her blend of humor, personal experiences, energy, and clarity has earned her a top spot as an industry speaker at various conferences including Microsoft TechEd, HP TechForum, HTCIA International Conference, Congress Netherlands, Electronic Crime Task Force Quarterly Meetings, and Novell BrainShare Conference.
This was first published in September 2008