[PATCH] Added NoDelay config option and nodelay subsystem option

[Tobias Ringstrom]

On Tue, 29 Jan 2002, Rick Jones wrote:

> > Let's see if I can explain it.  Consider a channel with a 2 s RTT,
> > infinite throughput, infinitely fast computers, no window updates, and
> > a Nagle timeout of 0.2 s.  The write column is the time the
> > process calls write(), and the send column is the time the TCP stack
> > releases the packet on the wire.  Req is a small request packet
> > (<<MSS), and Rsp is a large response packet (>>MSS).
> 
> There is no such thing as a Nagle timeout.  There is a delayed ACK
> timeout. Indeed, the two interact, but they should not be merged :)

Right you are, but that changes the flow to:

Write  Send   Signal       Arrival   
-----------------------------------
0.0    REQ1 sent           1.0
0.01   REQ2 queued               (nagle)
1.0    RESP1 sent          2.0
2.0    REQ2 sent           3.0
2.0    REQ3 queued               (nagle)
3.0    RESP2 sent          4.0
4.0    REQ3 sent           5.0
4.0    REQ4 queued               (nagle)
5.0    RESP3 sent          6.0
6.0    REQ3 sent           7.0
7.0    RESP4 sent          8.0

So it takes 8 seconds instead, which is even more pathetic, and adding
more overlapping would not help.  Now you may say that I should merge
the requests into one packet.  Ok, let's do that, but let's also
assume that transmission of the response takes 0.1 seconds due to
limited throughput.

Write  Activity            Arrival
------------------------------------
0.0    REQ1 and REQ2 sent  1.0
1.0    RESP1 sent          2.1
1.0    RESP2 sent          2.2
2.1    REQ3 sent           3.1
2.2    REQ4 queued                 (nagle)
3.1    RESP3 sent          4.2
4.2    REQ4 sent           5.2
5.2    RESP4 sent          6.3

Still pathetic, mostly since we cannot merge REQ3 and REQ4.

Nah, the whole point of Nagle is to prevent several small packet on the 
wire, which is exactly what we need to do overlapping requests.

> On balance I think you got it right. If you do not ever have enough
> reqest/response data to match the bandwidth delay product of the link,
> you will probably have the occasional delay from Nagle and Delayed ACK. 
> 
> As you get closer and closer to matching the bandwidth delay product,
> the responses/requests will start clocking each other onto the network,
> and you will no longer "see" the dleayed ACK timouts in the transfer
> rate.

Then I'll assume an infinitely fast computer (which should not
influence the result), and a 1 s RTT link with a throughput of one
response packet per second.  The bandwith delay product is 2 packets,
thus we need two outstanding request at any time.  I'll also assume
infinitely short request packets.

0.0  REQ1 and REQ2 sent  (will arrive at 0.5)
0.5  REQ1 arrives
     RESP1 is sent (link busy until 1.5, will arrive at 2)
     REQ2 arrives
     RESP2 is queued (link busy)
1.5  RESP2 is sent (link busy until 2.5, will arrive at 3)
2.0  RESP1 arrives
     REQ3 is sent  (will arrive at 2.5)
2.5  REQ3 arrives
     RESP3 is sent (link busy until 3.5, will arrive at 4)
3.0  RESP2 arrives
     REQ4 is queued       (NAGLE!!!)

Without nagle, the network would be perfectly saturated, but with nagle, 
it seems that it will not.  Prove me wrong!

/Tobias