From owner-freebsd-net Mon Nov 29 17: 4:40 1999 Delivered-To: freebsd-net@freebsd.org Received: from pail.ircache.net (pail.scd.ucar.edu [128.117.28.5]) by hub.freebsd.org (Postfix) with ESMTP id EFA021563A for ; Mon, 29 Nov 1999 17:04:36 -0800 (PST) (envelope-from rousskov@ircache.net) Received: from localhost (rousskov@localhost) by pail.ircache.net (8.9.2/8.8.7) with ESMTP id SAA18923; Mon, 29 Nov 1999 18:03:59 -0700 (MST) (envelope-from rousskov@ircache.net) Date: Mon, 29 Nov 1999 18:03:59 -0700 (MST) From: Alex Rousskov To: Mark Summerfield Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark, Thanks for a great overview! We will certainly use your opinion and the sources you quote in our discussions with the vendors. I should mention that in our tests we disable Nagle as well. IIRC, the original motivation for disabling Nagle algorithm was, again, avoiding extra delays, especially on persistent HTTP connections. A single persistent connection is limited to about 5 requests per second with Nagle enabled due to 200msec delays (recall that HTTP requests are usually small).. Out ultimate goal is to simulate a realistic TCP stream with FreeBSD (within the performance constrains that we have). Based on David Greenman's and your opinion, delayed ACKs should be disabled (and that is our current setting). Thanks again, Alex. On Tue, 30 Nov 1999, Mark Summerfield wrote: > 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 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