From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] Nagle algorithm References: <3.0.6.32.20011122122050.00974e88@pop3.clear.net.nz> From: "Sean M. Doran" In-Reply-To: <3.0.6.32.20011122122050.00974e88@pop3.clear.net.nz> (Andrew Simmons's message of "Thu, 22 Nov 2001 12:20:50 +1300") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (sparc--netbsd) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Nov 2001 11:57:00 +0100 Topicbox-Message-UUID: 290cc5be-eaca-11e9-9e20-41e7f4b1d025 Andrew Simmons writes: > What's wrong with Nagle? What's RIGHT with Nagle: - bigger packets, on average - more bytes/packet -> less wasted header overhead - more bytes/packet -> fewer packets per bit per second both of these are very good for the network, since the cost of modern day high-speed networking is driven by header processing and is pps limited, while the cost of practical networking (last mile, and in places like New Zealand) is driven by total amount of traffic, and you don't want to pay for headers rather than data useful to the end user - Nagle does not inflate the congestion window or delay during a bulk transfer: if there are lots of bytes being transmitted, the Nagle delay doesn't happen Moving Nagle into the application, as is suggested later in the thread, is awkward: it needs to know the segment size, which is affected by the receiver's advertised MSS, the local MTU and the path MTU. The latter two of these can change during the lifetime of a TCP conversation. The usual complaint about Nagle is that it punishes applications which deliberately exchange short packets. However, it is almost always possible to turn Nagle off on a per-connection basis, for those (relatively rare) applications which are upset by the increased transmit delay. The problem with simply "eliminating" Nagle is that a bulk-transfer application which DELIBERATELY schedules lots of small writes that do not queue at the TCP send level, will generate lots of small packets. This causes the TCP congestion window to inflate faster, and gives such applications an unfair advantage over applications which make larger writes that queue at the TCP send level, where they can be coalesced. The inflated congestion window means that when congestion does happen (TCP deliberately provokes it), the small-write/small-segment application will get a larger share of the bottleneck's bandwidth. This is perverse behaviour, since the application in question is a less efficient bandwidth consumer, since it generates more header data per user datum. The generation of large amounts of small packets should always been seen as antisocial. Sean.