Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-control-00.txt)

[Andi Kleen <[e-mail]>]

On Thu, Aug 13, 1998 at 03:31:06AM +0200, [e-mail] wrote:
> > Most BSD implementation (at least Free/NetBSD) don't have the problem, 
> > because they simply send an ACK every second packet, no matter how big
> > the packets were (this means BSD will send more acks than linux in some
> > situations)
> 
> I just got the latest FreeBSD source.  The following part of code has not
> changed.

[...]

You're right, FreeBSD does not do this. I just looked at the NetBSD source
and somehow believed FreeBSD did the same. Seems I was wrong.

In NetBSD the TCP_SETUP_ACK macro controls the ACK behaviour

#define	TCP_SETUP_ACK(tp, ti) \
do { \
	if ((tp)->t_flags & TF_DELACK || \
	    (tcp_ack_on_push && (ti)->ti_flags & TH_PUSH)) \
		tp->t_flags |= TF_ACKNOW; \
	else \
		TCP_SET_DELACK(tp); \
} while (0)


And then in the fast packet receive path:

	TCP_SETUP_ACK(tp, ti);
	if (tp->t_flags & TF_ACKNOW)
		(void) tcp_output(tp);

This means FreeBSD has a similar problem to Linux when the path changes
and the MTU shrinks during a connection then it'll go into delayed ACK
mode even for bulk data. NetBSD fixed it. The FreeBSD algorithm seems to
match the original 4.4BSD-Lite code as described in Stephens TCP/IP Ill. V.2

-Andi