From owner-freebsd-net Tue Nov 30 16:27: 7 1999 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 87E531561D for ; Tue, 30 Nov 1999 16:26:50 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id QAA34701; Tue, 30 Nov 1999 16:25:43 -0800 (PST) From: Archie Cobbs Message-Id: <199912010025.QAA34701@bubba.whistle.com> Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs In-Reply-To: <199911292249.OAA27538@implode.root.com> from David Greenman at "Nov 29, 1999 02:49:36 pm" To: dg@root.com Date: Tue, 30 Nov 1999 16:25:43 -0800 (PST) Cc: rousskov@ircache.net (Alex Rousskov), freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Greenman writes: > >The vendors also say that Linux TCP stack does not emit that many ACKs > >while not suffering from extra delays that default FreeBSD settings > >create (i.e., Linux folks allegedly found some magic "golden middle" > >that satisfies everybody). We have not verified these claims. > > It could be that delayed ACKs aren't delayed as long in Linux. We could do > the same thing in FreeBSD by shortening it down to say 10ms or something. That > would allow the ACKs to be aggregrated with the character echoes while still > keeping the response time fairly quick. Delayed ACKs are evil in other ways, > however. For one thing they add noise and additional delay to the estimated > RTT. Do the delayed ACK's have a fixed timeout, or is it proportional to the estimated RTT? It seems like in the former case, you're always going to find a situation where the timeout is too long. To avoid this the delayed ACK timeout should be some percentage of the estimated RTT. And as long as the ACK timeout is not much more than the variance in the estimated RTT, then how can you get into that much trouble with Nagle? Moreover, in practice, when a packet comes in there is often an immediate reply or no reply, so short timeouts shouldn't 'just miss out' too often (in effect, only if by coincidence). I'm curious because I just went through all this while implementing PPTP, which uses GRE and a similar RTT estimate, delayed ACK, etc. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message