In message <200501272032.39380.abuse@spamalicious.com>,
"Charles M. Hannum" writes:

>I've implemented some more changes to TCP, but I'd like some input on whether 
>they make sense and are worthwhile before committing them.
>
>1) dupseg_fix_=true from NS: do not count a segment with completely duplicate 
>data as a duplicate ack.  This can occur due to duplicate packets in the 
>network, or due to fast retransmit from the other side.

Seems reasonable.  "NS" means the ISI/ACIRI/et.al network simulator?
I'm used to seeing it written "ns", or "ns-2").  If so, that's a good
guide to what the TCP research community views as current best
practice.


>2) dupack_reset_=false from NS: do not reset the duplicate ack counter or exit 
>fast recovery if we happen to get data or a window update along with a 
>duplicate ack.

Ditto.


>3) In the "very old ack" case that itojun added, send an ACK before dropping 
>the segment, to try to update the other side's send sequence number.

If Itojun is trying to kludge up a defense against the long-lived-TCP
(BGP) sequence-number guessing attacks, then sending an ACK with
current sequenc number defeats the purpose of the change.  I would
therefore not send the ACK.


>4) Check the ssthresh crossover point with >= rather than >.  Otherwise we 
>start to do "exponential" growth immediately following recovery, where we 
>should be doing "linear".  This is what NS does.
>
>
>There are still a couple of outstanding questions:
>
>a) When in fast recovery and processing a dataless duplicate ack, we silently 
>drop urgent pointer updates (by using "goto drop").  Is this correct?

I'd say not correct, but BSD's handling of URG has never quite matched
what (for example) Bob Braden says it should be. The touchstone I
would use is: do whatever is right for telnet usage.

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

Good question: why do we? If the sending incurs a drop, the receiver
starts sending dupacks, and the receiving process read()s a bunch of
queued data from its buffer as the post-drop segments arrive, then
we'd expect(?) a dupack with an updated window.

Maybe an artifact of how NS simulates application reading of
simulated-TCP data?  I dunno.