der Mouse wrote:
> > We should not.  RFC-1123 clearly sets the onus the other way (that
> > is, as we have it now).
>... 
> (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.
> 
Hey Mouse, you've been around nearly as long as I, but I'm not reading 
it the same as you....

The MUST is to "disable".  Therefore, the default has to be "enable".  
(There's no other way to enable.)  Modus Tollens.


> 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.
> 
GreenDragon is a game company, so I've done a bit of game networking 
in my time. ;-)  This sounds more like a buffering and execution 
design problem.  Turning off Nagle only helps here as something in your 
message design is prompting the execution at the other end, which in 
turn sends a message prompting execution at the original end, causing 
oscillation.  You're merely masking a bug. 

Nagle and delayed ack are about being kind to your neighbors.  They 
souldn't be turned off except in the most unusual circumstances.
-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32