Date: Tue, 30 Nov 1999 12:36:47 +1100 From: Mark Summerfield <m.summerfield@ee.mu.oz.au> To: Alex Rousskov <rousskov@ircache.net> Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: <199911300135.MAA10058@mullian.ee.mu.OZ.AU> In-Reply-To: <Pine.BSF.4.05.9911291803230.18884-100000@pail.ircache.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 18:03 29/11/99 -0700, Alex Rousskov wrote: >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).. Well, if you're going to quote my opinion, I want to make it clear that I'm opposed to the blanket disabling of Nagle by default -- that's what TCP_NODELAY is there for (ideally to be used only in those applications that really need it, in the opinion of well-informed programmers - hah!) As the newsgroup thread I referenced before shows, there is some debate regarding the need for Nagle. My opinion is that those opposed to it do not fully understand what it is for, and its impact on the NETWORK (as opposed to individual apps). I said in that thread (in a posting entitled "We need Internet police" http://x21.deja.com/=dnc/getdoc.xp?AN=475043248): "It does seem to me that the whole debate is the result of people having completely different views of what's important. On the one hand, the pro-Nagle lobby make the very valid point that Nagle is designed to avoid the kind of congestion problems that can occur if large amounts of data are sent in lots of small packets instead of a smaller number of large packets. The anti-Nagle lobby contends that in practice there are many situations in which certain applications inherently generate small transactions over TCP which are going to get sent in small packets anyway, whether they go immediately or after a "Nagle-delay" and which are therefore taking a pointless performance hit. "The solution is *not* to have Nagle disabled by default, because then many badly-designed or implemented applications may just congest the network, and make life more miserable for the rest of us." I went on to propose a fairly draconian solution (which was really just a modified version of what's actually proposed for networks -- e.g. ATM -- which must maintain "real" quality-of-service guarantees). However, my opinion is that if everyone disabled Nagle by default, the Internet (or parts of it) would be at risk of regular congestion collapse. The fact that this does not happen suggests that Nagle is generally not disabled by default. I have no idea how much traffic is generated by applications that do set TCP_NODELAY (or do the equivalent). RFC1122 says that Nagle SHOULD be implemented, and that where it is, it MUST be possible for applications to selectively turn it off. >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). Depends what you mean by "realistic" -- perhaps we have been a bit unfair on your vendors. If they are telling you that the distribution of ACKs they are seeing in your simulated environment is different from that observed in the wild, maybe you should listen to them? If, on the other hand, you are telling them that their equipment performs poorly in the presence of entirely plausible (and possibly representative) traffic, maybe they should be listening to you? Maybe both? If you want to be sure that your traffic is "realistic" you will need actual measured statistics from those parts of the Internet in which your vendors' equipment is used, for comparison. Otherwise you're just making stuff up ;-) 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?199911300135.MAA10058>