> But in this case there was just a very minor update of the window (142
> bytes of a 32k window). Maybe the window should be frozen when the
> stack is sending dup acks (and the window is already big enough).

In my understanding, such a small window update would not be sent in
order to reduce the number of ACKs.  (A TCP window update is sent when
2 MSS or more bytes of data are received, or 1/2 or more of receive
buffer of data are received, since the last ACK is sent.  I guess
MSS=1460 in your trace.)  So, the ACK would be a dup ACK.

> Missing the fast retransmit really kills (interactive) performance.

Even if we counted the minor window update as a dup ACK, we need one
more dup ACK to kick Fast Retranmit.  I mean, we need one ACK and
three dup ACKs (totaled four) to kick FR.

I am not sure SACK would help your example, because the number of
dup ACKs in your trace is less than three.

I think Limited Transmit [RFC3042] would solve your problem.

Regards,
Noritoshi Demizu