>> One wonders if, given that more apps seem to have performance issues
>> with Nagle's algorithm than need it, if we shouldn't invert the
>> sense and explicitly set Nagling for rlogin and telnet and disable
>> it for other applications.
> We should not.  RFC-1123 clearly sets the onus the other way (that
> is, as we have it now).

(a) ITYPM 1122; 1122 4.2.3.4 discusses Nagle, and 1123 does not contain
the string "Nagle", nor does 1123's table of contents show anything
that looks as though it would cover it.

(b) It's not clear to me that 1122 specifies which way it should
default.  The quote is

            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.

Implementing it and defaulting it to off follows both the MUST and the
SHOULD here, as far as I can see.  (Whether it's a good thing is a
completely different question.)

Unless your "clearly sets the onus [to default it on]" comes from
somewhere else, in which case I'd be interested to hear where.

Incidentally, I have a program that sends data mostly unidirectionally
over a TCP connection, in smallish bursts (I haven't done stats, but my
guess is that a typical burst fits in a single Ethernet packet) at some
30-50 Hz.  It's a game display, and delays such as Nagle can introduce
make it border on unplayable.  Normally it works fine, but it would
occasionally get into a state where screen updates were delayed and
then occurred burstily.  This oscillation would continue for several
seconds, eventually quieting down.  I'd been meaning to trace the
connection and see what was happening, but this thread made me try
turning on TCP_NODELAY (on both ends, though bulk data flows only one
way); it hasn't gone into oscillation since.  I cite it here as an
example of a real application where Nagle severely impairs usability.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B