What timer prevents TCP window update packet loss - tcp

Question

When the receiver of a TCP data stream closes its receive window (or, more exactly, the window is closed by the sender filling it up), there will be a flurry of packets which Wireshark would identify as TCP ZeroWindow and TCP Keep-Alive (repeated ACK with same sequence number). Some time later the receiver will send a new ACK to re-open the window (TCP Window Update) and data will start flowing again.
What TCP timer mechanism ensures that the window update packet is retransmitted if data does not start flowing?
Here is the sequence of packets that I see at the end of a connection (more data is expected):
No. Time Source Destination Protocol Length Info
122160 21:24:37.421824 192.168.15.121 72.21.81.253 TCP 60 41200 > http [ACK] Seq=462 Ack=2984241 Win=5152 Len=0
122162 21:24:37.445528 72.21.81.253 192.168.15.121 TCP 1514 [TCP segment of a reassembled PDU]
122163 21:24:37.445796 72.21.81.253 192.168.15.121 TCP 1514 [TCP segment of a reassembled PDU]
122164 21:24:37.446087 72.21.81.253 192.168.15.121 TCP 1514 [TCP segment of a reassembled PDU]
122171 21:24:37.481802 192.168.15.121 72.21.81.253 TCP 60 41200 > http [ACK] Seq=462 Ack=2988621 Win=784 Len=0
122184 21:24:37.744838 72.21.81.253 192.168.15.121 TCP 838 [TCP Window Full] [TCP segment of a reassembled PDU]
122185 21:24:37.745048 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122190 21:24:38.014841 72.21.81.253 192.168.15.121 TCP 60 [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0
122191 21:24:38.014993 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122232 21:24:38.534437 72.21.81.253 192.168.15.121 TCP 60 [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0
122233 21:24:38.534599 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122314 21:24:39.564525 72.21.81.253 192.168.15.121 TCP 60 [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0
122315 21:24:39.564680 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122361 21:24:43.403052 192.168.15.121 72.21.81.253 TCP 60 [TCP Window Update] 41200 > http [ACK] Seq=462 Ack=2989405 Win=119904 Len=0
122892 21:25:45.161896 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122902 21:25:45.373289 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122927 21:25:45.813267 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122936 21:25:46.693275 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122956 21:25:48.453337 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123009 21:25:51.983392 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123061 21:25:59.033566 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123262 21:26:13.153852 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123460 21:26:41.394469 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
The receiver re-opens the window at 21:24:43 and hears nothing more from the sender. A minute later the receiver times out the connection (the close is initiated by the application) and sends a series of FIN-ACKs which remain unacknowledged.
It looks like communication with the sender is simply lost (the capture was taken on the receiver's network). If not, then should one always expect an acknowledgement to the FIN-ACKs, even after a period long enough for the peer to have forgotten the connection?
Despite what RFC1122 may say on the matter, is it (common) practice for large Internet servers to do something different in this regard, perhaps as counter-DoS measures?

Answer 1

As you noted, the receiver sends a new ACK with an updated window size once space is available in its receive window.
In order to handle the case where that ACK is lost, the sender keeps a "persist timer" that will occasionally re-transmit a packet (a "window probe") in order to test the waters and see if there is indeed unreported receive space.
The value of the persist timer is not specified explicitly but rather is a function of the calculated round-trip time along with some exponential backoff. Full details are in RFC1122 in section 4.2.2.14, here: https://www.rfc-editor.org/rfc/rfc1122#page-92
The trace provided looks like something in the middle is blocking return traffic from the server. My guess would be that your NAT gateway (192.168.. is not a valid address on the Internet so something in between is doing network address translation) has decided the connection is gone and is refusing to forward additional packets back from the server.