Index | Thread | Search

From:
Otto Moerbeek <otto@drijf.net>
Subject:
Re: Add sysctl to disable Nagle's algorithm (RFC 896 - Congestion Control)
To:
Theo de Raadt <deraadt@openbsd.org>
Cc:
Alexander Bluhm <bluhm@openbsd.org>, Job Snijders <job@openbsd.org>, tech@openbsd.org
Date:
Tue, 14 May 2024 21:29:33 +0200

Download raw body.

Thread
On Tue, May 14, 2024 at 10:15:53AM -0600, Theo de Raadt wrote:

> Alexander Bluhm <bluhm@openbsd.org> wrote:
> 
> > On Mon, May 13, 2024 at 06:41:55PM +0000, Job Snijders wrote:
> > > Perhaps in the future - after more study & contemplation - we'll to
> > > change this sysctl's default from 0 to 1?
> > 
> > The common network API is to enable TCP_NODELAY to turn off Nagle's
> > algorithm.  If we change that default, userland software has to be
> > written differenty for OpenBSD.
> 
> Correct.  Toggling this system-wide will affect a tremendous number of
> applications which have not been studied (and are not being studied).
> I guess the theory is if this toggle existed, some people would study
> it.
> 
> I think they can study it today by making a new kernel.  The proposal
> contains no pre-study of this.
> 
> The proposal mentions .1% of the network speaking applications which
> manually turn it off.  It doesn't contain a discussion from the other
> side.  That's weird.
> 
> > What is the default on FreeBSD and Linux?  If they have switched,
> > mainstream developers will do it differently.  Then we could also
> > adapt.
> 
> Noone has switched to turning it off by default.
> 
> > Although for most cases Nagle does not improve performance, it still
> > depends on the protocol above TCP if that is the case.  I doubt
> > that a global sysctl can handle this.
> 
> Nagle also has a large number of unmentioned side effects.  It reduces
> receive interrupts on the other side.  It reduces transmit-complete
> interrupts on this side.  By bundling data, it probably accidentally
> prevents some latency inspection problems, etc etc etc
> 

Nagle does not work for well for interactive stuff and cases where
small amounts of data go back and forth. So programs doing that type
of traffic disable it. This is all very well known and should not
cause surpsises.

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. 

The current default is fine, I don't think we want to differ from
well known patterns here.

	-Otto