Date: Tue, 30 Nov 1999 10:54:11 +1100 From: Mark Summerfield <m.summerfield@ee.mu.oz.au> To: dg@root.com, Alex Rousskov <rousskov@ircache.net> Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: <199911292353.KAA02746@mullian.ee.mu.OZ.AU> In-Reply-To: <199911292249.OAA27538@implode.root.com> References: <Your message of "Sun, 28 Nov 1999 17:05:13 MST." <Pine.BSF.4.05.9911281645230.12493-100000@pail.ircache.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 14:49 29/11/99 -0800, David Greenman wrote: >>Interesting! In our benchmarking environment we disable delayed ACKs as >>well. However, we were recently attacked by several vendors of the >>products we test. The vendors claim that turning delayed ACKs off >>produces too many ACK packets compared to a "real" TCP stream they >>observe in practice. Those "extra" ACKs might overflow their >>NICs/adapters when they are close to their performance capacity. > > That sounds very lame. It *is* very lame. If you want an authority to quote, how about John Nagle? Earlier this year there was one of the periodic mild flame-fests that erupt in comp.protocols.tcp-ip when someone seeking improved performance suggests that the Nagle algorithm is a liability. The discussion, as archived on deja.com (search for the subject "Turning off Nagles [sic] algorithm") contains 87 posts, of which the most succinct and informative is the single contribution from John Nagle himself. It can be found at http://x32.deja.com/=dnc/getdoc.xp?AN=477899304 . You can read the full text for yourself, but to summarise: 1) The thing that bites people is the nasty interaction that can occur between delayed ACKs and Nagle. 2) This happened because the two algorithms were developed independently and contemporaneously -- i.e. Nagle developed his algorithm on a network which did not have delayed ACKs. 3) Delayed ACKs are a nasty hack which are unnecessary, and John Nagle would like to see them removed from the TCP spec. 4) Nonetheless, if you do see poor performance due to the interaction, it does mean that your application is probably not well-designed, and you *should* be able to fix it with some judicious modification to the code. >>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. The host requirements RFC (1122) says that TCP SHOULD implement a delayed ACK of less than 500ms in duration. It is therefore perfectly legal to reduce it to 10ms. It's also legal not to do it. You might ask your vendors why their products can't handle perfectly legal behaviour, if they claim this is a problem. Perhaps you are exposing them to "worst case" conditions, but even so, Nagle alone should be sufficient to prevent congestion collapse unless the vendors' equipment is brain-damaged (and you'd think they'd want to know if it is?!) Mark ---- Dr. Mark Summerfield Australian Photonics Cooperative Research Centre Photonics Research Laboratory Dept. of Electrical and Electronic Engineering The University of Melbourne Parkville, 3052 AUSTRALIA Phone: +61 3 9344 7419 Fax: +61 3 9344 6678 Email: m.summerfield@ieee.org WWW: http://www.ee.mu.oz.au/staff/summer/index.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911292353.KAA02746>