title: What timer prevents TCP window update packet loss
body: <p>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 <code>TCP ZeroWindow</code> and <code>TCP Keep-Alive</code> (repeated ACK with same sequence number). Some time later the receiver will send a new ACK to re-open the window (<code>TCP Window Update</code>) and data will start flowing again.</p>
  
  <p>What TCP timer mechanism ensures that the window update packet is retransmitted if data does not start flowing?</p>
  
  <p>Here is the sequence of packets that I see at the end of a connection (more data <em>is</em> expected):</p>
  
  <pre>
  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
  </pre>
  
  <p>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.</p>
  
  <p>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?</p>
  
  <p>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?</p>