[clue-tech] Downside of increasing TCP window size?

[Jim Ockers]

Hi everyone,

We have a very low bandwidth, very high latency TCP/IP connection
that we're trying to optimize.  Is there a downside to using large
TCP windows on an Important web server, when only a few of the clients
are on high latency connections and most clients are on low latency
connections?

In other words, if we change the window sizes on our Important web
server, what will (or could) break?

The Layer 2 is a 4800 baud MSAT satellite dialup to the PSTN and our
own terminal server (with an analog modem) using Linux pppd on both
ends.  The TCP connection is an SSL request to an apache web server, 
using the Perl Net::SSL libraries via LWP::UserAgent and possibly 
HTTP::Request.

Here's a diagram:

Client <-RS232-> MSAT satmodem <-> PSTN <-> terminal server <-> SSL web server
PPP CLIENT <------------------------------> PPP SERVER
TCP CLIENT <------------------------------------------------->  TCP SERVER

The client, terminal server, and SSL web server are all Linux of
varying flavors.

Anyway it appears that if we can make the TCP socket from the remote
to the server using large TCP windows, the connection is more reliable
(less likely to time out) and faster (data moves more quickly overall).
I think this is due to the well known TCP ACK issue on high latency 
networks.

I'm tuning the kernel TCP as follows:

echo "4096 131072 131072" > /proc/sys/net/ipv4/tcp_wmem

We've tried changing the tcp_rmem to some small value but it doesn't
seem to make too much of a difference.

I know the window size should be a multiple of the MTU (576) but I'm
not sure exactly how to do the calculation.  Round trip ping times are
1700 to 1900ms.  Small MTUs mean that less data has to be resent if
a TCP retransmit is necessary; a 1500 byte MTU is a really huge 
packet on a 4800 baud connection.

Anyway the Important web server shall remain unchanged unless I can
provide some proof that Nothing Bad Will Happen if we change its TCP
window sizes.

Thanks for any advice or clues,
Jim

-- 
Jim Ockers, P.Eng. (ockers at ockers.net)
Contact info: please see http://www.ockers.net/