For a new client, we simulated a worst-scenario connection, where packets cross the North American continent twice from an ADSL connection, yielding a connection with at least 180ms of rtt. The customer's lab reported throughput of ~500Kb/s out of their 3.0 Mb/s ADSL (theoretically the bottleneck). Customer was not pleased.

We ran to our graphs, which showed plenty of capacity. Scratching our heads, we got the customer to load ttcpw. Scaling up the receive window size, we could ship almost 3.0 Mb/s to the customer. So why wasn't windows' tcp stack scaling?

Turns out the lab used an old windows PC (windows 2000) subject to the following issue, where the tcp stack's receive window defaults to ~17KB. This means that at the end of a 180ms rtt link, the theoretical upper limit to a TCP transaction's throughput equals:

= receive window size in bytes * 8bits/byte / rtt in seconds = 17520 bytes * 8 bits/byte / 0.180 seconds =~ 779 Kb/s

Supposedly, M$ fixed that in later releases and started supporting rfc1323. You just have to make sure you enable it....