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

[Lloyd Wood <l.wood@eim.surrey.ac.uk>]

On Tue, 4 Apr 2000, Joo Changhee wrote:

> > > So, what I am willing to indicate is that  an ACK of some "next expected"
> > > packets should not be delayed.
> > > for example, The sender send W packets from seq. 1. 
> > 
> > large initial windows?
> 
> No. I just exemplify a case.

seq. 1 is something of a special case.


> > > Assuming the first W-1
> > > packets are dropped and the last W-th packet arrived at the receiver,
> > > after any kind of retransmission method, the sender retransmit the dropped
> > > packet from seq. 1. At this time, the receiver has "next expected" seq. 1
> > > but the receiver should not delayed the ACK of it. 
> > 
> > Why shouldn't the receiver delay the ACK? Delayed acks have to start
> > somewhere; you're basically saying that delayed acks should be
> > exclusively second-in-order-and-onwards, rather than
> > first-in-order-and-onwards. I'd argue that this first packet is not
> > out of order as far as the window and its needs are concerned, and is
> > therefore correctly delayed.
> 
> It may cause performace decrease. In the view of the sender, it is in
> recovery period and expects that the receiver may send an ACK per every
> packet. 

That's not a sender expectation.

Normally, when delayed acks are used, the RTT estimates at the sender
include the delay (since the sender just sees a round-trip time.)
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?

What you seem to be suggesting is the following algorithm:

that the first 'next expected' in-order-packet received causes an ACK
to be issued then sets a flag, any out-of-order packet clears this
flag and issues an ACK when received, and only if a 'next expected'
packet is received and the flag is _already_ set is the delay timer
started.

You'd need to implement this algorithm and the flag yourself. An
enhancement would be to have the sender tell the receiver that it has
put itself in the recovery period (using one of those reserved 6 bits
in the TCP header, say), so that the receiver has additional
information to decide whether to delay acks or not (and can indicate
whether an ACK was deliberately delayed or not using that selfsame
bit.)

These are modifications to the delayed-ack algorithm, not bugfixes.


[*] M. Allman, "On the Generation and Use of TCP Acknowledgements",
    ACM Computer Communication REview, Vol. 28 No. 5, October 1998.
http://www.acm.org/sigs/sigcomm/ccr/archive/1998/oct98/ccr-9810-allman.html


> If timeout occurs, its window increases very slowly.

Yes, but the wait-for-timeout period is based on srtt, and so
should include the effects of the delay (with connection startup being
a special case.) So a timeout with delayed acks shouldn't be more
likely than a timeout without delayed acks, because the wait
period for the timeout with delayed acks should be bigger (give or
take 500ms rounding.)


> Otherwise, (NewReno with partial window deplation or rate halving
> algorithm), the sender try to adapt the window size to half after recovery
> ends to increase its performace. Hence it may reduce more than half if the
> receiver does not send immediately for a packet arrival. 
> 
> I heard that it is a known bug and corrected in current version of TCP in
> linux and BSD.

News to me. Details? Pointers?

L.

> Changhee Joo                           jchee@netlab.snu.ac.kr
> School of Electrical Engineering, Seoul National Univ., Korea

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>