b) NS does not consider whether the send window is being updates
  when it decides whether it has a duplicate ack.  Why do we?
  (Obviously if we didn't, we'd have to change the "goto drop"s to
  avoid throwing out the window update.)

If there's a window update, the other side could have sent the ack
becaues of that, rather than because another segment from us arrived.
So it doesn't imply what a dupack implies for congestion control
purposes.

I don't see any reason not to process urgent pointer updates on
dupacks.  I wonder if a case can be made that an urgent pointer update
also disqualifies an ack from being used to clock out another packet.
But it would be odd for a peer to send data and then later decide to
move the urgent pointer.

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