[PATCH] Added NoDelay config option and nodelay subsystem option

[Tobias Ringstrom]

On Tue, 29 Jan 2002, Nicolas Williams wrote:

> Yes. But the problem probably is that the old Nagle algorithm and TCP
> congestion control in general probably needs revision to really work in
> newer networks.

Why would Nagle not work well for pty sessions over modern networks that
happen to have a high latency link?

As for improved TCP congestion control, I thought ECN would help a lot 
once it is in wide-spread use.

> > >     - turn on TCP_NODELAY for all sessions that have active port or
> > >       display forwarding or which are not exec sessions (myself)
> > 
> > If we can agree that Nagle should be on for pty sessions, it should be 
> > on iff the current ssh connection only contains pty sessions, i.e. no port 
> > forwarding channels, no sftp, no x11, etc.
> 
> Yes, but, wrt SFTP, I think that the two consecutive small write()s that
> lead to Nagle being triggered can and SHOULD be coalesced. I've not
> looked at sftp/sftpd's source, but you have; how hard would that be to
> implement?

It's not very easy.  Delaying the window adjustment packet, as described
below, and implementing a timeout would take some time.  I'm not very keen
on doing it.  It would be a very good thing, no doubt.

> > > The latter can probably be done by coallescing the write()s of those two
> > > packets that trigger Nagle.
> > 
> > That requires delaying the window adjustment packet until we have another
> > packet to send, and to send them together.  A timeout is also needed, but 
> > the real problem is that this breaks down (I think) when we have 
> > overlapping requests, which I really hope we will have real soon.  In 
> > other words, sftp wants TCP_NODELAY.
> 
> But, I thought your analysis pointed to Nagle as the bottleneck and, it
> seemed to me when I read it, that you were saying that overlapping
> requests wouldn't improve performance as much as disabling Nagle would.

That differs from case to case.  Over localhost on Linux 2.4, overlapping 
requests did not help very much with Nagle enabled, but between two 
machines in a LAN, it did help a lot, even with Nagle enabled.  Note that 
one of the machines was not very fast in that case.

> Well, not triggering Nagle seems to me like a more noble thing to do
> than just disabling it.

What I'm saying is that when we have overlapping requests, we need to
disable nagle, even if we could merge the window update packets with the
requests or responses.  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).

Write  Send   Signal     Arrival
-----------------------------------
0.0    0.0    Req#1 ->   1.0
0.01   0.2    Req#2 ->   1.2   (nagle delay)
1.0    1.0    <- Rsp#1   2.0
1.2    1.2    <- Rsp#2   2.2
2.0    2.2    Req#3 ->   3.2   (nagle delay)
2.2    2.4    Req#4 ->   3.4   (nagle delay)
3.2    3.2    <- Rsp#3   4.2
3.4    3.4    <- Rsp#4   4.4

Did I get it right, or did I miss something?  As you can see, transmitting 
four data packets took 4.4 seconds.  Without Nagle, it would have taken 4 
second.

/Tobias