You'll forgive me if I don't take too authoritatively this experimentation given you may not be aware of the various parameters that could affect his tests. Case in point:
Quote:
|
One downside with large windows is if there is congestion/loss, a retransmit is more expensive.
|
Wrong on multiple levels. Firstly windows start small and increase if transmission is smooth and quick - the whole point of TCP windows is that they are congestion control and respond to congestion / loss conditions. They must increase to higher levels in order to allow maximum throughput on high BDP links (Google it). This is a common feature of all TCP stacks, the only differences as far as windows go being how aggressively they increase window size post-loss and how they manage retransmission / duplicate acknowledgement.
Secondly a retransmit is not more expensive due to window sizes, it's more expensive due to cumulative or selective acknowledgements. When a retransmit happens window sizes will be reduced in case that retransmit was forced by congestion. Windows govern how much data can be sent before an acknowledgement must be received not how frequently data must be acknowledged and therefore how much data can be lost in one shot.
For your tests to be taken in any way seriously you need to be taking packet captures and analysing them so that you can see the sliding windows, retransmits, acknowledgement pattern, etc.
EDIT: The only negative impact of TCP windows being excessively large is in terms of buffers within kernels and routers being eaten as TCP pushes out big bursts of data to try and fill windows, although I'm sure given all the servers you run professionally you knew that. I've more than once had to have customers adjust buffer sizes on routers when devices behind them are running HSTCP to fill a long, wide pipe.