Re: delayed ACKs for retransmitted packets: ouch!

Kacheong Poon <Kacheong.Poon@Eng.Sun.COM> Tue, 03 November 1998 19:08 UTC

X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f
Date: Tue, 03 Nov 1998 11:08:00 -0800
From: Kacheong Poon <Kacheong.Poon@Eng.Sun.COM>
Reply-To: Kacheong Poon <Kacheong.Poon@Eng.Sun.COM>
Subject: Re: delayed ACKs for retransmitted packets: ouch!
To: Neal Cardwell <cardwell@cs.washington.edu>
Cc: tcp-impl@lerc.nasa.gov
In-Reply-To: "Your message with ID" <Pine.LNX.4.02A.9811021421340.26785-100000@sake.cs.washington.edu>
Message-ID: <Roam.SIMCSD.2.0.4.910120080.27665.kcpoon@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
Sender: owner-tcp-impl@lerc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1534
Lines: 28

> The TCP congestion control draft (draft-ietf-tcpimpl-cong-control-00.txt)
> specifies that "Out-of-order data segments SHOULD be acknowledged
> immediately, in order to trigger the fast retransmit algorithm." Many
> implementations -- at least FreeBSD 3.0 and Linux 2.1, and probably most
> others, i'm guessing -- interpret this by sending an immediate
> acknowledgment only if a data segment they receive is above a hole in
> their receive queue. That is, the ACK only if the sequence number is above
> and not equal to rcv_next (see Figure 27.15 in Stevens vol 2 for the code
> snippet that does this in Net/3 and FreeBSD).

That is quite interesting.  Solaris sends an ACK immediately in this case.
That is why we never saw this problem when we added NewReno to Solaris 2.6.
Maybe you can try to use a Solaris 2.6 or 7 as the receiver and see what
will happen.  Also compare the result using a Solaris sender.

> So what i'm asking is this: is it a good idea to clarify or extend the
> notion of "out-of-order" data that should be ACKed immediately, in such a
> way that data segments that fill in a hole in the receive queue should be
> ACKed immediately? This would seem to alleviate this problem with New
> Reno. Are there other scenarios where it would make things worse instead?

Actually, I always think that a segment which fills a hole is an out of
order segment.  IMHO, this looks like a bug in the implementation.  Maybe
this can be another item in the known problem draft?

							K. Poon.
							kcpoon@eng.sun.com

Re: delayed ACKs for retransmitted packets: ouch! Kacheong Poon