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.

I think you are correct in that the window update would not _cause_ an
ACK to be sent.  But consider a window update happening in the middle
of a sequence of what really are duplicate acks (in that they are sent
to ack packets arriving when there is missing data):

data1
        ack
data
        (does not arrive)
data
        dupack for data1
data
        dupack for data1

                [data read, window updated, no window update sent]
data
        ack for data1 with different window.

This last ack really is a dupack in this case, but can't be treated as
such, and I think that was the point of the notion of 'freezing the
window', and continuing to report the old window, perhaps until an ack
is sent which advances the ack point.

 
-- 
        Greg Troxel <gdt@ir.bbn.com>