Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!BERSERKLY.CRAY.COM!dab
From: dab@BERSERKLY.CRAY.COM (David Borman)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: telnet and Nagle's algorithm
Message-ID: <9105211655.AA06268@berserkly.cray.com>
Date: 21 May 91 16:55:03 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 87

> From tcp-ip-RELAY@NIC.DDN.MIL Sat May 18 16:53:34 1991
> Date: 18 May 91 20:00:09 GMT
> From: sdd.hp.com!news.cs.indiana.edu!ux1.cso.uiuc.edu!usenet@ucsd.edu  (Doug McDonald)
> Organization: University of Illinois at Urbana
> Subject: Re: telnet and Nagle's algorithm
> References: <9105172007.AA28847@ftp.com>
> Sender: tcp-ip-relay@nic.ddn.mil
> To: tcp-ip@nic.ddn.mil
> 
> 
> In article <9105172007.AA28847@ftp.com> ljm@FTP.COM (leo j mclaughlin iii) writes:
> >Yet more bad news.  The primary reason for allowing Nagle's algorithm to be
> >turned off was X-Windows.  Nagle's algorithm is very bad for any application
> >(such as X-windows) with short bursts of high priority traffic.  For these
> >sorts of applications, most (all?) vendors who do Nagle allow 'no Nagle' as
> >an option when opening a connection.
> >
> >Thus, it is the *application* which can turn off Nagle, not the user.  Even
> >worse from your point of view, the one application you would have a very
> >tough time convincing people should be un-Nagled, the one application which
> >generates the overwhelming majority of 'wasteful' small packets in the
> >Internet, the one application for which Nagle was designed, is telnet.
> >
> 
> I simply don't underestand this. If there is ONE application for which
> instantaneous sending of individual bytes is important, it is telnet.
> Otherwise user interaction could simply go to hell. Consider what
> would happen if, for instance, you tried to do something like an
> arcade game over Telnet. Or cursor control in an editor.
> 
> Besides, if you want a Telnet with Nagle, can't you simply have the
> Telnet program ask for no Nagle???
> 
> 
> Doug McDonald

Actually, the lack of the Nagle algorithm is what can cause user interaction
to be degraded.  The whole point of the Nagle algorithm is that it reduces
the number of tiny packets being sent/received, thus reducing both system
and network overhead.

From RFC 1122, section 4.2.3.4:

	A TCP SHOULD implement the Nagle Algorithm [TCP:9] to
	coalesce short segments.  However, there MUST be a way for
	an application to disable the Nagle algorithm on an
	individual connection.
	...
	The Nagle algorithm is generally as follows:
		If there is unacknowledged data (i.e., SND.NXT >
		SND.UNA), then the sending TCP buffers all user
		data (regardless of the PSH bit), until the
		outstanding data has been acknowledged or untill
		the TCP can send a full-sized segment (Eff.snd.MSS
		bytes; see section 4.2.2.6)

In BSD networking code, it is more or less:
	1) On the first write, send the data, even if it is
	   less than the MTU.
	2) Queue up successive writes until:
		a) we have MTU bytes of data to send
		b) an ACK comes back from the previous data
		c) a timer goes off.
	3) Send as much data as we can in one packet, and go
	   back to step 2.

The Nagle algorithm uses the fact that tiny packets are going out,
and the other side will be acking the data immediatly, because there
will be data coming back from the remote side and it can piggyback the
ACK on the data.  In rlogin/telnet, when doing single character, remote
echo, you know that the ACK will be coming back fairly quickly, because
the other side will be sending back a packet with the data to echo to the
terminal.  So, rather than dribbling out packets with one byte of data
in each packet, the Nagle algorithm allows the packets to be clumped
together.  When you are logged in across a long delay network, and you
see your typed characters being echoed in clumps of three or four
characters, that is usually the Nagle algorithm at work.

If you have an application that is sending out small packets, and
the remote side can't do anything when it gets the first packet because
it needs the data in the next packet, then  the Nagle algorithm will
hurt you.  (This is a sitution when user level stdio is helpful, or
using one writev() call instead of several write() calls to write non-
contiguous data (e.g., headers seperate from data) will avoid the problems
that the Nagle algorithm can cause.)

			-David Borman, dab@cray.com