Date: Mon, 29 Nov 1999 18:03:59 -0700 (MST) From: Alex Rousskov <rousskov@ircache.net> To: Mark Summerfield <m.summerfield@ee.mu.oz.au> Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: <Pine.BSF.4.05.9911291803230.18884-100000@pail.ircache.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9911291803230.18884-100000>