Question on ACKs on out-of-window packets

[Srinivas Neginhal]

Hi,
     I had a question on how the current tcp_input()/tcp_do_segment() code handles ACKs on out-of-window packets.
     Specifically, The code to handle packets which fall entirely to the left of the window.

     Here is the scenario I am analyzing right now.


1. Client has sent out a window worth of data to the server and is waiting for acks, it can't send any more data.
2. The server is also sending data to the client.
3. The client has received everything the server had to send and has sent sent an ack for the last byte.
4. Further, for what ever reason the ACK the client sent to the server takes longer than usual time to get to the server.
5. The server decides to retransmit earlier packets. And it starts way back.
6. It retransmits an old packet but now piggybacks an ACK for all the data the client sent the server.

Now, say, this old packet has the following attributes
Sequence number: 100000 
Acknowledgement number : 300000
Packet Len: 1448 bytes.


Say the client has the following 
rcv_nxt: 105000.
wl1: 104000.


This entire packet falls to the left of the receive window. The ack on this packet would be processed but the window update won't happen.

Now at the same time if the server receives and processes the latest ACK the client sent in step 3 above (for 105000), it would stop all retransmission.
The server has no more data to send to the client. 
Also, since the server has already sent an ACK for all the data the client sent it, it won't send a pure ACK either.
The client would be stuck with a snd_wnd of 0.

At the least, wouldn't this trigger unnecessary window probes?
In my particular case, the persist timer has not been triggered either since tcp_output() never got called.

Solaris seems to have changed their window update code 
http://blogs.sun.com/kcpoon/entry/solaris_tcp_window_update

This is not really as per the RFC but would fix the problem I am dealing with.

Any thoughts?

Regards,
Srinivas