In a TCP connection, the server transmits the data in a series of sends and acknowledgements. That is, the server sends a little bit, awaits the client's acknowledgement, sends a little more, awaits the client's acknowledgement...and so on until the entire transmission is complete.
The amount of data that the server sends before it waits for the client's acknowledgement is referred to as a window. Its purpose is to control the flow of data. Too large a window results in excessive retransmission and network congestion. Too small a window results in suboptimal throughput. The optimum window size is affected by a wide variety of ever-changing factors, including end-to-end network configuration, transmission media, and traffic load. For this reason, TCP implementations continuously adjust window size to reflect current conditions, starting from an initial value determined during TCP connection establishment. This initial value is calculated by the sending TCP, based upon a default receive window size supplied by the receiving TCP.
The challenge is finding the optimum default receive window size for your own network environment. A good default value is key to sustaining the highest rate of throughput. A bad default value can really bog it down. While no one window size works best for everyone, let's look at a few examples...
Consider a typical Intranet environment. Here, client workstations pull data from file, application, or web servers located on the same 10Mbps LAN segment. The theoretical throughput limit in this scenario is 10 million bits per second divided by 8 bits per byte, or 1,250 Kbytes per second. I found TCP throughput to peak around 700 Kbytes per second (5.6 Mbps) when transferring files between two Pentium PCs running Windows 95. Note that performance was abysmal at values of 2,918 bytes or smaller. Reasonable throughput levels were achieved at 2,919 bytes or larger, with peak performance found between 2,944 and 4,096 bytes. When the value was set to 8,192 bytes, the default in an off-the-shelf Windows 95 setup, throughput dropped by 23 percent!
Now consider a remote office or other high-speed remote access environment. Here, client PCs access servers located in another subnetwork, connected via a single 64 Kbps ISDN (integrated digital services) B channel. Performance tests conducted during the Strategic Networks 1996 ISDN router and bridge evaluation [link to http://www.snci.com] indicate that larger values yield higher throughput (up to 61.7 Kbps at 24,576 bytes) when transferring files between two subnets connected via ISDN. Since ISDN is digital, data loss is relatively low. But when compared to ethernet, propagation delay is high. Therefore, a larger window size lets more data "fill the pipe" between sender and receiver without incurring much of a retransmission penalty.
Suppose you're a typical telecommuter or home PC user. You have a 28.8 Kbps analog modem for dial access to file and web servers on the public Internet. Your theoretical throughput is limited to 28,800 bits per second divided by 8 bits per byte, or 3.6 Kbytes per second. Just how close can you get to this limit? I managed just under 2.8 Kbytes per second (22.4 Kbps) when transferring files from my ISP's FTP server to my Windows 95 Pentium PC by setting the default value to 24,576 bytes. While it is modest, this is still a 14 percent improvement over the 2.4 Kbytes per second (19.2 Kbps) achieved with the MSTCP default window of 8,192 bytes. This improvement would save you almost five minutes when downloading a 5MB file.
Low-end home users still struggling along with a 14.4 Kbps analog modem won't find any relief here. With a theoretical limit of just 1.8 Kbytes per second, I found throughput to hover around 1 Kbyte per second (8 Kbps) for almost all values tested. Interestingly, I found throughput peaked when the value was set to 2,919 bytes. Why is this value so special? If you assume a maximum transmission unit (MTU) value of 1,500 bytes, 40 bytes of protocol header, and 1,460 bytes of user data, two TCP packets would be used to carry 2,920 bytes. When the value is large enough to allow two full packets to flow across the TCP connection, you get a "pipeline" effect.
How to modify the default value in Windows 95
The default receive window size in
Microsoft's MSTCP implementation for Windows 95 is called "DefaultRcvWindow."
Follow these steps to modify this parameter:
Please note that my analog
dial test results may have been affected by network congestion
between my PC and my ISP's FTP server, as well as the workload
of the server itself. Your own results may vary. My advice is
to try downloading the same file at a few different DefaultRcvWindow
values to determine the optimum value for your own configuration.
What if you use your PC for
both LAN and WAN access? Alas, there is only one DefaultRcvWindow
parameter and it affects all interfaces on your PC. Look for
a happy medium - you may find yourself satisfied with a 24,576
byte DefaultRcvWindow, boosting your WAN throughput without adversely
affecting LAN throughput when compared to performance under the
default value.
Try it. Hey, what have you
got to lose? You can always set the parameter back to default.
Seize the window of opportunity! The DefaultRcvWindow, that
is.
HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
VxD
