Tcp – Where is the maximum packet size for TCP identified as 65,535

A simple Internet search will turn up a lot of information on this subject. if you add rfc to your search, you will get links to the RFCs. For instance, RFC 793, TRANSMISSION CONTROL PROTOCOL:

Note that when the receive window is zero no segments should be acceptable except ACK segments. Thus, it is be possible for a TCP to maintain a zero receive window while transmitting data and receiving ACKs. However, even when the receive window is zero, a TCP must process the RST and URG fields of all incoming segments.

Edit:

Based on the comments and discussion, the timer is not paused, it continues to run and may expire. If the ACK for the expired timer is received before the window size is reset, the timer is moot since the segment(s) was acknowledged. If the window size is reset before the ACK is received, the timer has already expired since it continued to run, and the sender will immediately resend the unacknowledged segment(s). It will not resume a paused timer and wait for it to expire.

Your reasoning is correct, more or less. The window scale value for each side can only be set once, in the SYN packet at the beginning of the TCP session, and thus sets an upper bound to the window size (66536 x WS) that can be advertised by that receiver. For this reason, it is in the receiver's best interest (if throughput is a desired feature of the session) to set the largest possible WS value that its buffer can handle in order to maximize throughput during the TCP session.

However, there are multiple other algorithms and factors that play into what window sizes values are actually advertised, particularly at the start of a session. These include TCP slow start, TCP congestion control (e.g. additive increase multiplicative decrease), Nagle's algorithm, etc. Since TCP windowing is one of the primary methods for balancing throughput, controlling congestion, and endpoint resource utilization, a lot can go into actual advertised TCP window sizes.