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
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.
On 11/29/06, Phillip Susi <[email protected]> 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
>>>>> "Matt" == Matt Garman <[email protected]> writes:
Matt> On 11/29/06, Phillip Susi <[email protected]> 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
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.
> 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.
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.
Phillip Susi <[email protected]> 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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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.