In message <rmi1xc64n5e.fsf@fnord.ir.bbn.com>,
Greg Troxel writes:

>  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.

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).

>So it doesn't imply what a dupack implies for congestion control
>purposes.

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.  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.



>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?  With gigabit and ten-gigabit NICs with
interrupt moderation, and TCPs that fuse all the ACKs from an
moderated-interrupt burst into a single ACK, doing ACK-clocking on
individual _packets_ is ... rather outdated, if not downright
undesirable.

OTOH, e2e is the appropriate place for discussing whether to implement
ACK clocking by couting ACK-bearing segments, or by the count of data
(octets) being ACKed.



>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?