[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Tue, 4 Apr 2000, Mark Allman wrote:

> > Delayed acks _do_ cause a performance decrease - that much is well
> > known[*] - but sending an ACK per packet in the recovery period to

Quick Q: what exactly do we mean by 'recovery period'? I keep
thinking of it as the time the sender takes to restore cwnd_ to its
previous value, but you're obviously thinking of something else...


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

ns delayed acks do this.

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

but they don't do that AFAIK. I think this could be implemented in ns
by changing:

        if (delay_timer_.status() != TIMER_PENDING &&
                                th->seqno() == acker_->Seqno()) {

to 

        if (delay_timer_.status() != TIMER_PENDING &&
             th->seqno >= maxseen_ && th->seqno() == acker_->Seqno()) {

in DelAckSink::recv(), to decrease the amount of times the timer is
set to when the left edge isn't being moved along to fill a gap.

Joo, is this what you were getting at?


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

Hmmm. The last 'To provide feedback' sentence? Hinges on how you
define 'gap' or 'part of a gap'. It's very tempting to read this as
saying that immediate ACKs should be used throughout for in-order
packets as part of that Extremely Large Gap above all received
segments (maxseen_) is filled in, contradicting the SHOULD of delayed
acks.

L.

mind the gap.

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

<[email protected]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>