Subject: a question about delayed ACK policy

From: Joo Change-hee <[email-masked]>
Date: Sat, 13 Nov 1999 10:55:27 +0900

I have a question about delayed ACK policy that is widely used in
current TCP
implementation and makes the receiver send an ACK per two packets.

my question is that if out-of-order packet is received but it is next
expected one, then the receiver should delay corresponding ACK ?

for example, if the sender experiences mulitple packet drops in a
window,
then timeout occurs in TCP Reno. the sender already send packets
between "snd_una" and "snd_max". TCP starts its slow-start again.
At the receiver's view, it receives some packets between "snd_una" and
"snd_max" and it expects the next packet ("next_") will be the packet
that has
seq number of "snd_una".
To make it easy, let's thinks the worst case. The receiver receves only
one
packet that has seq number of "snd_max". Then the sender in its
slow-start
send packets burstly from seq number of "snd_una".
At this point, the receiver should use delayed ACK ?

I think that the receiver should not delay ACKs because the packets are
out-of-order. But it seems that some implementations delayed the
correponding ACKs because they test only whether the received packet has

"next_" seq number.

Is that right? I am not convinced.
Any helps are welcome.

Thanks.

---

From: Neal Cardwell <[email-masked]>
Date: Fri, 12 Nov 1999 21:13:26 -0800 (PST)

> expected one, then the receiver should delay corresponding ACK ?

I think your intuition is right. If the packet arrives at rcv_nxt but the
receiver already has packets buffered above rcv_nxt, then the receiver
should send an ACK immediately to expedite the loss recovery process,
whether it's a timeout and slow start or Hoe-style fast recovery based on
partial ACKs. This is noted in RFC 2581, as well as the New Reno RFC. If i
remember correctly, BSD-derived stacks and recent Linux stacks do this
correctly, but early Linux 2.0.x stacks unfortunately delay ACKs in this
case.

neal