Otto Moerbeek <otto@drijf.net> wrote:

> My worry is that disabling Nagla always will affect apps that are not
> interactive but write quite a lot of data in relatively small chunks
> into the socket, expecting the kernel to do the buffering and create
> large packets.  Without Nagle, the same app will create many small
> packets.  I don't see a benefit in that. I don't think we want every
> app to create a buffering layer that knows about the best packet sizes
> and things like that. 

I agree.

The proposal talks about a few applications which are better with nagle
off by default.  Most of those applications have already turned off
Nagle, after deciding that the cognitive load of driving their small
write system calls via single internal buffing layering is too complicated
(that's ssh, that is most http services, etc).  In that software, Nagle was
manipulated by a developer after systematically studying & modifying the
application as a whole.

But applying it to all applications, just because 'few applications
prove Nagle bad'?  That is backwards.  It needs to prove that the entire
application ecosystem is MAJORITY improved by disabling Nagle.

I strongly doubt it is improved.  I suspect a majority of software is
different from the few well-known ones disabling Nagle -- and I'm sure a
few which intentionally leave Nagle enabled -- furthermore I suspect the
majority of software gains full-system benefits from this 'teeny buffer
bloat' layer.

It mostly has to do with what the internal IO subsystem of a program looks
like.  Does it use stdio, does it use raw writes, does it use BIO, etc.
(That's where short writes due to intersecting layers of API).

So I suspect "Nagle always bad" would need to be disproven before we
give people a dangerous knob -- which a segment of the user community
would toggle, and thus increase our cognitive load when trying to
diagnose their vague bug reports in the future...