To better understand TCP window Size Scaling we first need to understand the TCP Windows, thus I am copying the section I wrote from 1.1.e Explain TCP Operations here…
Window size (in Bytes)-
1.Receive window size:
Each host in a TCP connection sets their receive window size meaning this is the most the host will accept before he actually looks at it. Think of it as grabbing chunks of data from the buffer then reading it. That chunk is the receive window. This window is set by the receiver and is for not overloading the receiver. This is usually set by the amount of buffer space the NIC has on the receiving end. The receive window is also how much data can be received before needing to send an ack.
2.Congestion/send window size:
Each host in a TCP connections has a send/congestion window size to avoid congestion, this window gradually increases until detects packet loss, then it sets the window size back to the original value and begins TCP slow start. The congestion window is sender controlled. The method of raising the window until packets drop is how TCP finds its max bandwidth. Other things like ECN exist to fix this and not rely on packet loss The congestion window CANNOT be larger than the receive window of the other end host, otherwise packets will make it to him, but be dropped by him (the receiver). This process of first starting to send uses the “TCP slow start” algorithm.
Window scale: Allows us to get past the limitation of a max window size of 65535 (16 bits). The window scale is a multiplier for the receive window size.
These windows and the window scale is what the TCP slow start operation uses, at first it doubles the window size for every segment it gets acked, then up to the threshold, it will start increasing linearly.