TCP Window Scaling for Satellite Connections

Solution 1:

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.

Solution 2:

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.

Solution 3:

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.