A satellite connection generally has a RTT around 500ms. Connections generally suffer sub-optimal transfer speeds, in spite of large amounts of bandwidth because TCP acknowledgements take too long to arrive.
My understanding is that a good way to address this problem with TCP connections is to set the TCP Window size to the connection speed (in bits) multiplied by RTT (in seconds). So a 1mbps connection over satellite should have a window size of 512kb.
What pitfalls are involve in this? Are there any other similar tweaks that should be made to optimize for satellite connections? I understand that many modern operating systems will modify the window size automatically, but will they be aggressive enough to make window sizes large enough to work for satellite communication?
As an aside, I'm going to assume that a large window size is not desirable on networks that frequently drop packets, as the retransmission will be at the window size, and you may dedicate much of your bandwidth to retransmission overhead.
Thank you, I'm still learning a great deal about networking and appreciate your input.
You should generally use a TCP stack that implements proper Window scaling. But of course you are right that your window size needs to mach that bandwidth-delay-product (BDP). In case you have a varying BDP you can set the window size to something you'd expect as a common "worst" case. Interestingly enough most connections don't suffer from too much if the window size is large than the BDP (it shouldn't be way too large of course), but show degraded performance if the window size is much smaller than the BDP.
To check if your TCP/IP stack is properly increasing the window size you should employ Wireshark or any other traffic sniffer. You can either directly look at the window size flag in the header (with the scaling factors in mind!). Wireshark can also show the effective window size by taking the scaling factor into account.
Check this tutorial on how to plot your TCP window size as a function of time here.
This is totally academic because nobody runs TCP over satellite connections. I don't know a single satellite provider that does this. They all run satellite-specific protocols over the satellite and place the TCP endpoint at the ground station.
When a machine on the network sends a TCP SYN packet to the satellite terminal, the satellite terminal sends a TCP proxy request to the satellite. This instructs the ground station to open a TCP connection to some server on the Internet. The ground station speaks TCP to the Internet server. The satellite terminal does not speak TCP over the satellite, but instead speaks a protocol optimized for satellite use. The ground station acts as a proxy between the satellite terminal and the Internet server.
For the sake of convenience there are bandwidth-delay product calculators available - one such calculator is here. As to large windows causing issues in the event of packet loss - that's pretty much exactly why TCP windowing is variable. Upon packet loss the window size will decrease, allowing for less data in flight and a consequent reduction in transmission speed. After a period of time the window size will renegotiate.
Your latency actually isn't that bad for satellite - a 1s RTT @ 1M is only a 125K window. A good number of modern operating systems would easily support this right out of the box, so additional modifications might not be required.
As an aside - some have had very good luck with the various WAN optimizers available on the market. These tend to both optimize TCP window sizes as well as utilizing caching and compression to both push more through the link and improve apparent responsiveness.