Re: sshd should not use TCP_NODELAY

On Tuesday, 8th June 2004, Brian Feldman wrote:

>On Tue, Jun 08, 2004 at 04:27:35PM +0400, Andrey Chernov wrote:
>> Just FYI, PuTTY client have an option to enable/disable TCP_NODELAY per 
>> user needs. If it will be an option, it should go to client part too.

I assume this PuTTY option affects the client side only.  There's no code
in the openssh server to make TCP_NODELAY optional when in interactive mode.

>It sounds like there needs to be an option to switch from TCP_NODELAY to
>either one of the SSH1-type buffering mechanism or to a sockopt that can
>be set on both ends.

Are you suggesting that the client should be able to tell the server to
use or not use TCP_NODELAY?  That may be enough to satisfy me, but I don't
know how that is done while staying compatible with other ssh servers.

>I don't think TCP_NODELAY is really the problem,
>but I bet that without it there would be enough delay in-between various
>multi-character control sequences (arrow keys, etc.) that they'd
>become useless.

I'm starting to think that the misuse of TCP_NODELAY is the real problem.

If a program sets this flag there must be recognition of the fact that
tinygrams are the natural result, and the program should take pains to
not generate many of them in quick succession.  This is the extra work
necessary to safely take advantage of the reduced latency that TCP_NODELAY
gives.

This implies that sshd should coalesce small messages if there are more
than a few of them in a row.  The old ssh1 pty reading code does this
fairly well (though I think it could use 1k instead of 256 bytes as its
target).  For an interactive application like ssh, adding 10ms to coalesce
pty output before sending it is no problem.

So there are at least two ways of improving this situation: disable
TCP_NODELAY, or use it carefully by buffering pty output.

As for your objection to removing TCP_NODELAY because it will introduce
delay between multi-character control sequences, this doesn't seem to be
a problem.  A single key press causes multiple bytes to be sent down the
pty to ssh, which receives them in one go, and sends them in a single
packet.  Anyway, I think TCP_NODELAY is probably safe to use on the client
end as it's normally sending just individual keystrokes, which are too slow
to overwhelm any intermediate networking device.

Stephen.