Skip to main content
Support

KB Article #182994

GUIDELINE: TCP window scaling and SecureTransport's SSH service

Problem

The TCP windows scaling factor set by the SecureTransport's SSH service is always 1, regardless of the OS configuration. This might cause "TCP Window Full" alerts and could reduce the upload speed to the ST Server.


Solution

The ST SSH server has a couple of configuration parsameters, correlating to the TCP window scaling. They are system properties called recvBufferSize and sendBufferSize which should be imported in the start_sshd script:


JAVA_OPTS="-DrecvBufferSize=<buffer_size> -DsendBufferSize=<bufer_size> $JAVA_OPTS"


The values of the buffer sizes are in bytes and their relation to the value of 65535 (the original TCP packet length) is forming the so-called TCP window scale. The following table can be used as a reference:



Scale value and factor are based on the relation of the actual window size and the value of 65535


Having a window size (i.e. the buffer sizes from the start_sshd script) set to 262140 would result in having a scale value of 4 (net.ipv4.tcp_window_scaling=4).


It is not recommended to use very large values for the SSH script's buffers as they might result in having too many frame retransmissions or consuming an increasing amount of memory with larger buffer sizes. For most cases a scale value of no more than 16 is acceptable.


The below picture shows the TCP packet analyzer with recvBufferSize=262140 in the start_sshd script - there are no "TCP Window Full" alerts, and the negotiation is on WS=4: