[PATCH] Added NoDelay config option and nodelay subsystem option

[Rick Jones]

> > 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!

OK, so REQ's are very very small, Nagle is ON, it takes 1s to completely
toggle a RESP onto the wire and and the RTT is one second, so the
one-way latency is 0.5 seconds. I'll assume a 200 millisecond standalone
ACK, but the specific there isn't too important.

         App        TCP      Link        TCP         App
0.0  send(REQ1)  xmit(REQ1)
     send(REQ2)  queu(REQ2)
0.5                                     recv(REQ1)  read(REQ1)
                            busy(RSP1)  xmit(RSP1)  send(RSP1)
1.0                         busy(RSP1)
1.5  read(RSP1)  recv(RSP1)
                 xmit(REQ2)
     send(REQ3)  queu(REQ3)
2.0                                     recv(REQ2)  read(REQ2)
                            busy(RSP2)  xmit(RSP2)  send(RSP2)
2.5                         busy(RSP2)
3.0  read(RSP2)  recv(RSP2)
                 xmit(REQ3)
     send(REQ4)  queu(REQ4)

and the process will repeat. So, I think you were too generous initially
when you sent REQ1 and RES2 onto the wire at the same time at time 0.0.

Now, what happens if the number of requests that the app sends is
bandwidthXdelay +1?

        App        TCP        Link        TCP         App
0.0  send(REQ1)  xmit(REQ1)
     send(REQ2)  queu(REQ2)
     send(REQ3)  queu(REQ3)
0.5                                     recv(REQ1)   read(REQ1)
                            busy(RSP1)  xmit(RSP1)   send(RSP1)
1.0                         busy(RSP1)
1.5  read(RSP1)  recv(RSP1)
                 xmit(REQ2+3)
     send(REQ4)  queu(REQ4)
2.0                                     recv(REQ2+3) read(REQ2)
                            busy(RSP2)  xmit(RSP2)   send(RSP2)
                                                     read(REQ3)
                                        xmit(RSP3)   send(RSP3)
2.5                         busy(RSP2)
3.0  read(RSP2)  recv(RSP2) busy(RSP3)
                 xmit(REQ4)
     send(REQ5)  queu(REQ5)
3.5                         busy(RSP3)  recv(REQ4)   read(REQ4)
                                        xmit(RSP4)   send(RSP4)
4.0  read(RSP3)  recv(RSP3) busy(RSP4)

OK, I can see now that it will stop where you had things stop, so
clearly bwdelay+1 is insufficient, I think we need bwdelay+2 in this
instance with a socket buffer size of bwdelay. I tried to diagram it out
and it was ugly, but I think it result in at least two REQ's being set
at once each time after the intial singleton and tripple.

The reason to have the socket buffer only bwdelay is so that when that
first tripple hits the third response cannot go into the socket buffer
and hit TCP until the fifth(?) request arrives, so the fourth response
ACK's both the four request and the fifth request. (It does this because
it was sent by the app to TCP after the fifth request arrived because
the fifth request acked the second response) I think I have that right
though I am in a maze of twist passages :)

rick
-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...