Like the story of Goldilocks and the Three Bears, too small or too large of an RWIN just won't do.

Important Notes:
Use the following RWIN sizes for BellSouth FastAccess and be done with it. The rest of the FAQ is purely academic.
FastAccess Extreme 3.0Mbps and 6.0Mbps = 63888
FastAccess Ultra 1.5Mbps = 52272
FastAccess Lite 768Kbps = 52272
Although the Broadband Reports Tweak Test offers very good general information, it may give erroneous or misleading recommendations. It provides a range for your RWIN and is not an accurate, individualized analysis.
Don't rely on speed test sites to make small changes to your RWIN. They usually use a small file and can't accurately measure the true overall efficiency of your services.

What's happens if my RWIN is too small
A small RWIN creates more unnecessary traffic and delays. Remember you must stop inbound traffic while the acknowledgement is sent and received by transmitting end. These inefficiencies are not easily measured with standard speed test simply because they use such a small file, however the overall efficiency is greatly reduced.

What's happens if my RWIN is too big
An RWIN larger than 65535 is never recommended for FastAccess DSL for three major reasons:
1. Although a larger rwin is possible, anything above 65535 will automatically turn on Window Scaling which is not supported or implemented correctly on all networks and internet devices.

The TCP window field, however, is only 16 bits wide, allowing for a maximum window size of 64KB. The TCP designers must have thought that nobody would ever need a larger window than that. But 64KB is not even close to what is needed in many situations today. The solution to this problem is called "window scaling." It is not new; window scaling was codified in RFC 1323 back in 1992. It is also not complicated: a system wanting to use window scaling sets a TCP option containing an eight-bit scale factor. All window values used by that system thereafter should be left-shifted by that scale factor; a window scale of zero, thus, implies no scaling at all, while a scale factor of five implies that window sizes should be shifted five bits, or multiplied by 32. With this scheme, a 128KB window could be expressed by setting the scale factor to five and putting 4096 in the window field.

To keep from breaking TCP on systems which do not understand window scaling, the TCP option can only be provided in the initial SYN packet which initiates the connection, and scaling can only be used if the SYN+ACK packet sent in response also contains that option. The scale factor is thus set as part of the setup handshake, and cannot be changed thereafter.

The details are still being figured out, but it would appear that some routers on the net are rewriting the window scale TCP option on SYN packets as they pass through. In particular, they seem to be setting the scale factor to zero, but leaving the option in place. The receiving side sees the option, and responds with a window scale factor of its own. At this point, the initiating system believes that its scale factor has been accepted, and scales its windows accordingly. The other end, however, believes that the scale factor is zero. The result is a misunderstanding over the real size of the receive window, with the system behind the firewall believing it to be much smaller than it really is. If the expected scale factor (and thus the discrepancy) is large, the result is, at best, very slow communication. In many cases, the small window can cause no packets to be transmitted at all, breaking TCP between the two affected systems entirely.

2. DSL and the underlying ATM/Ethernet network is a low latency transmission topology. Extremely large rwins work best with high bandwidth/high latency networks such as satellite. Satellite service creates a large amount of latency for the packet acknowledgements which decreases full bandwidth utilization. Remember, inbound traffic stops while the acknowledgement is sent and received by transmitting end. Since DSL doesn't have these inherent problems, you should not use extremely high RWINs.

3. As bandwidth goes higher the relative stability of the connection goes down. Many people with 6.0 may be right at the service edge for signal to noise and attenuation. That increases the chances of errors and/or packet loss. If a TCP packet is lost with a large rwin it will actually take more time to retransmit the packet(s) compared to a smaller rwin.

Andy Houtz DSL