[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ns] a small bug in delayed ACK ?
On Wed, 5 Apr 2000, Lloyd Wood wrote:
> 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...
Yes. but in case of NewReno (or other algorithm to recover from multiple
packet loss within a window without timeout), the current delayed ACK
implementation may fail to cwnd_ to its previous value during Fast
Recovery.
> > > 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?
Yes. In addtion, I think the condition can be reduced to 'th->seqno() ==
maxseen_' because
if th->seqno() > maxseen_, the packet is out-of-ordered.
if th->seqno() < maxseen_, the packet fill the hole or unnecessary
retransmitted packet
>
> > (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/>
>
>
>
>
>
-------------------------------------------------------------
Changhee Joo [email protected]
School of Electrical Engineering, Seoul National Univ., Korea
-------------------------------------------------------------