[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/>