> >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.
> 
> Yes, that too.  But there *could* also have been a drop event, as in
> the scenario I sketched in reply to Charles.  We can't tell which
> (without more info, ala SACK).

Sure - I thought this was the point of "don't reset dupack count, but
don't increase it", to be conservative about being sure dupacks mean a
packet arrived..

> It doesn't _nescessarily_ imply it; but it might.  I think you are
> right about what classical classical Reno did/does, but it seems more
> conservative to count the (same ACK, window update) segment as a
> dupack.

That causes the sender to send more, so I'd call it less conservative.
I was trying to err on the side of our TCP sending <= what should be
sent.

> OTOH, if there's still data segments in flight pipe, that
> data will trigger more dupacks.  And on the gripping hand, if we get a
> drop towards the end of a burst of segments, and the receiving app
> reads partway through the burst, and we treat the same-ACK-but-window-update
> segment during the burst as a non-dup-ack for Reno purposes, we'll wait
> a full retransmission timeout before recovering --- much as in the case
> Charles fixed.

Sure, but for any congestion control scheme one can posit a situation
where being \epsilon more aggressive it would avoid a RTO.

> >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.
> 
> Huh? In this day and age?

Sorry, I meant only in the limited sense of dupacks causing additional
data to be sent in fast recovery, not regular ack processing.  Along
the lines of joint window update/ack packets being possibly not due to
an arriving packet.

> >But it would be odd for a peer to send data and then later decide to
> >move the urgent pointer.
> 
> But is it illegal?  Can a telnet client be coerced into doing so?

In RFC792 I didn't find a prohibition on moving the urgent pointer,
and a notion that sending urgent data and then more urgent data is
normal.  So if our sender's window is closed, and the remote side
sends new data marked urgent, there could arrive a TCP packet that is
a dupack and updates the urgent pointer.

(The BSD "OOB" mechanism as used in rlogin is horribly broken from the
point of view of the TCP specification of urgent data, but I think
that's irrelevant to the current discussion.)