Re: [ns] a small bug in delayed ACK ?

[Mark Allman <mallman@grc.nasa.gov>]

> Normally, when delayed acks are used, the RTT estimates at the
> sender include the delay (since the sender just sees a round-trip
> time.)

Right.  Because we're not really attempting to estimate the RTT, but
more like the "feedback time".  In other words, how long we should
wait before retransmitting?  Any delay the receiver imposes on
generating an ACK clearly needs to be included in this "feedback
time", else we increase the chance for needless retransmits.

> Delayed acks _do_ cause a performance decrease - that much is well
> known[*] - but sending an ACK per packet in the recovery period to
> decrease performance degradation is something that AFAIK hasn't
> been explored in depth, much less agreed on/standardised. How does
> the receiver know that the sender is in recovery period?

Without getting into the details...

(1) We have standardized this behavior.  From RFC 2581 (proposed
    standard):

    Out-of-order data segments SHOULD be acknowledged immediately, in
    order to accelerate loss recovery.  To trigger the fast retransmit
    algorithm, the receiver SHOULD send an immediate duplicate ACK when
    it receives a data segment above a gap in the sequence space.  To
    provide feedback to senders recovering from losses, the receiver
    SHOULD send an immediate ACK when it receives a data segment that
    fills in all or part of a gap in the sequence space.

(2) I think this business with the flag is much too complicated.
    The above description from 2581 should dovetail into a nice
    receiver-side-only implementation of this idea, I think.

allman


---
http://roland.grc.nasa.gov/~mallman/