Subject: Re: More TCP changes for review
To: Greg Troxel <firstname.lastname@example.org>
From: Jonathan Stone <email@example.com>
Date: 01/27/2005 13:52:24
In message <firstname.lastname@example.org>,
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
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
>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
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?