[PATCH] Using TCP_NODELAY unconditionally

[Rick Jones]

> I suppose I could, but why exactly?  Are you looking for proof that it is
> Nagle that is indeed the performance killer?  It is easy to theoretically
> show how Nagle kills performance when you have a request-reply packet
> based protocol.  For example, when writing data to the server, the server
> replies with a small response packet (tens of bytes).  This response
> packet will not be transmitted immediately because of the Nagle algorithm
> is waiting for more data to form a full packet.  Since the client is
> waiting for the response before sending another write packet, performance
> drops radically, especially over a fast link.  Overlapping requests helps
> a bit, but if your link is very fast, you need many overlapping requests.
The way the Nagle algorithm is supposed to work is like this:
On every user send the code is supposed to go through this sequence of
pseudo logic:
1) is the quantity of data in this send, plus any queued unsent data
more than the MSS for the connection? if yes, send the data now
(modulo other constraints such as receiver window and congestion
window) if no, go to 2.
2) is the connection otherwise "idle"? that is, do we have no
unacknowledged data outstanding to the remote? if yes, send the data
now, if no, queue the data and wait.
So, in a simple synchronous request/response application (such as
might be simulated with a netperf TCP_RR test, the Nagle algoritm will
_not_ kick-in. Whenver one side goes to write the request or response
the connection will be "idle" Unless... the application writes its
request or its response in multiple send/write calls.
Now, where one _might_ see nalge with an app that does properly
present all logically associated data to the trasnport in a one send
is when that application wants to have multiple overlapping
request/response pairs on the same connection, and either the
requests, or the responses are smaller than the MSS of the
connection. 
at that point it becomes  a matter of timing as to whether or not any
delay induced by the interaction of nagle and the remote's ack policy
will come to pass.
> It is also easy to show it by transmitting a file over a high-speed
> network with and without TCP_NODELAY.  Without it, both the server
> and the client are mostly idle, and the network is not fully
> utilized.
Unidirctional bulk data transfer should _never_ run into an issue iwht 
nagle. the app is dumping data into the socket, and shoudl always be
creating at least an MSS of data to send. for example, at least a
"classic" ftp data connection should never need to set
TCP_NODELAY. the ftp app will keep calling send with file data, and
for any last little bi at the end, the close of the connectin will
flush.
rick jones