What happened to CONFIG_TCP_NAGLE_OFF?

What happened to CONFIG_TCP_NAGLE_OFF?

[Matt Garman]

I would like to globally disable nagling on my (2.6.9) system.  There
are several references on the web to the CONFIG_TCP_NAGLE_OFF kernel
config option.  However, it appears as though this no longer exists.

How might I achieve having TCP_NODELAY effectively set for all sockets
(by default)?  Is there a new/different kernel config option, a patch,
a sysctl or proc setting?  Or can I "fake" this behavior by, e.g.
setting a send buffer sufficiently small?

Thank you,
Matt

Re: What happened to CONFIG_TCP_NAGLE_OFF?

[Phillip Susi]

Matt Garman wrote:
> I would like to globally disable nagling on my (2.6.9) system.  There
> are several references on the web to the CONFIG_TCP_NAGLE_OFF kernel
> config option.  However, it appears as though this no longer exists.
> 
> How might I achieve having TCP_NODELAY effectively set for all sockets
> (by default)?  Is there a new/different kernel config option, a patch,
> a sysctl or proc setting?  Or can I "fake" this behavior by, e.g.
> setting a send buffer sufficiently small?

This is a bad idea and breaks api compatibility.  Nagle is very 
important for sockets being used for things like telnet.  Other 
applications, like ftp, should already disable nagle themselves.

Re: What happened to CONFIG_TCP_NAGLE_OFF?

[Matt Garman]

On 11/29/06, Phillip Susi <psusi@cfl.rr.com> wrote:
> > How might I achieve having TCP_NODELAY effectively set for all sockets
> > (by default)?  Is there a new/different kernel config option, a patch,
> > a sysctl or proc setting?  Or can I "fake" this behavior by, e.g.
> > setting a send buffer sufficiently small?
>
> This is a bad idea and breaks api compatibility.  Nagle is very
> important for sockets being used for things like telnet.  Other
> applications, like ftp, should already disable nagle themselves.

I don't want to change the API at all.  I'm using a closed-source, 3rd
party library.  Using strace, I can see that the library does *not* do
a setsockopt(...TCP_NODELAY...) on opened sockets.  Since I can't
change the library, I would like to patch and/or configure my kernel
so that all TCP/IP sockets default to TCP_NODELAY.

Also, if my understanding of Nagle is correct, I think you have that
backwards: Nagle should be disabled (i.e. TCP_NODELAY) for telnet,
mouse movements, etc: we always want to send our packets, regardless
of size or previous packet ACK.

Thanks,
Matt

Re: What happened to CONFIG_TCP_NAGLE_OFF?

[John Stoffel]

>>>>> "Matt" == Matt Garman <matthew.garman@gmail.com> writes:

Matt> On 11/29/06, Phillip Susi <psusi@cfl.rr.com> wrote:
>> > How might I achieve having TCP_NODELAY effectively set for all sockets
>> > (by default)?  Is there a new/different kernel config option, a patch,
>> > a sysctl or proc setting?  Or can I "fake" this behavior by, e.g.
>> > setting a send buffer sufficiently small?
>> 
>> This is a bad idea and breaks api compatibility.  Nagle is very
>> important for sockets being used for things like telnet.  Other
>> applications, like ftp, should already disable nagle themselves.

Matt> I don't want to change the API at all.  I'm using a
Matt> closed-source, 3rd party library.  Using strace, I can see that
Matt> the library does *not* do a setsockopt(...TCP_NODELAY...) on
Matt> opened sockets.  Since I can't change the library, I would like
Matt> to patch and/or configure my kernel so that all TCP/IP sockets
Matt> default to TCP_NODELAY.

Can't you use the LD_PRELOAD trick to force your own custom library to
override the closed library, so that you can change the socket options
to be how you want them?

Wouldn't that be easier, and be less likely to screw up the whole
system?  

You could override the socket() call, so that you just pass through
all the parameters your library sets, and then you just put in your
own setsockopt() call on the socket, and return it as normal to the
library?  Hacky, but should do the trick if you're careful.

John

Re: What happened to CONFIG_TCP_NAGLE_OFF?

[Phillip Susi]

Matt Garman wrote:
> I don't want to change the API at all.  I'm using a closed-source, 3rd
> party library.  Using strace, I can see that the library does *not* do
> a setsockopt(...TCP_NODELAY...) on opened sockets.  Since I can't
> change the library, I would like to patch and/or configure my kernel
> so that all TCP/IP sockets default to TCP_NODELAY.

That _IS_ changing the api.  Applications that wish to use nagle will no 
longer be able to because you will have changed the api to always 
disable nagle.

> Also, if my understanding of Nagle is correct, I think you have that
> backwards: Nagle should be disabled (i.e. TCP_NODELAY) for telnet,
> mouse movements, etc: we always want to send our packets, regardless
> of size or previous packet ACK.

No, nagle was invented specifically for telnet.  Without nagle, every 
character you type is sent in its own packet, which gives around 50,000% 
overhead.  Nagle was created to compact most of your keystrokes into a 
single packet.

Things like mouse movements should not be sent over TCP at all.  UDP 
makes a much better protocol for that kind of data since if a packet is 
lost, there is no need to retransmit the same data; instead you just get 
the next position update and don't care about where the mouse was during 
the dropped packet.

Re: What happened to CONFIG_TCP_NAGLE_OFF?

[Alan]

> No, nagle was invented specifically for telnet.  Without nagle, every 

No it was general purpose. It fixes some extremely bad behaviour in TCP
with congestion well beyond the "telnet" behaviour.

> Things like mouse movements should not be sent over TCP at all.  UDP 
> makes a much better protocol for that kind of data since if a packet is 

UDP is rarely appropriate because it has no congestion control. There are
more appropriate protocols but they are rarely implemented so TCP
generally gets used.

> lost, there is no need to retransmit the same data; instead you just get 
> the next position update and don't care about where the mouse was during 
> the dropped packet.

Re: What happened to CONFIG_TCP_NAGLE_OFF?

[Phillip Susi]

Alan wrote:
> No it was general purpose. It fixes some extremely bad behaviour in TCP
> with congestion well beyond the "telnet" behaviour.

Saying it is general purpose demeans it.  Nagle was created specifically 
to deal with the bad behavior that results from IO patterns like those 
created by telnet.  Obviously other applications can exhibit those same 
patterns.  Those that do not, have no need for nagle, so they can 
benefit from turning it off.

> UDP is rarely appropriate because it has no congestion control. There are
> more appropriate protocols but they are rarely implemented so TCP
> generally gets used.

UDP is highly appropriate because the congestion controls and other 
features of TCP are not required for this type of data, and in fact, 
tend to muck things up.  That is why the application needs to implement 
its own congestion, sequencing, retransmit and connect/disconnect 
controls; because the way TCP handles them is not good for this 
application.

People often use TCP because it is easier, but not optimal.

Re: What happened to CONFIG_TCP_NAGLE_OFF?

[Herbert Xu]

Phillip Susi <psusi@cfl.rr.com> wrote:
> 
> UDP is highly appropriate because the congestion controls and other 
> features of TCP are not required for this type of data, and in fact, 
> tend to muck things up.  That is why the application needs to implement 
> its own congestion, sequencing, retransmit and connect/disconnect 
> controls; because the way TCP handles them is not good for this 
> application.

Congestion control is always appropriate in a shared network.  Please
note that congestion control does not conflict with the objectives of
UDP.  For UDP, congestion control can simply mean dropping packets at
the source.  DCCP is a good replacement for UDP that has congestion
control.

In general it's much better to much better to drop packets at the
source rather than half-way through.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: What happened to CONFIG_TCP_NAGLE_OFF?

[Phillip Susi]

Herbert Xu wrote:
> Congestion control is always appropriate in a shared network.  Please
> note that congestion control does not conflict with the objectives of
> UDP.  For UDP, congestion control can simply mean dropping packets at
> the source.  DCCP is a good replacement for UDP that has congestion
> control.

That is why I said that the application should implement its own 
congestion control, just in a different way than TCP does that is more 
appropriate to the specific needs of the application.