Nagle & delayed ACK strike again

[Miklos Szeredi]

> > This time the problem is that the ssh server only sets TCP_NODELAY for
> > interactive (tty) sessions or if X11 forwarding is enabled.  Neither
> > of which are true for the use of the sftp subsystem.  This hurts
> > upload performance for sftp/sshfs.
> > 
> > I'm not sure why this hasn't cropped up earlier.  Were there any
> > TCP_NODELAY related changes in the sshd code recently?
> > 
> > Is there a reason not to enable NODELAY unconditionally?  Any reason
> > why the server end is different from the client (where NODELAY is now
> > uncoditionally enabled) in this respect?
> 
> I suspect that past discussions might be interesting reads - should be 
> an an archive somewhere I suspect.
> 
> My personal stance is that 99 times out of ten, if an end-user 
> application speeds-up when it sets TCP_NODELAY, it implies the end-user 
> application is broken and sending "logically associated" data in 
> separate send calls.

You tell me, is X protocol broken?  Is SFTP broken?  I don't think
SFTP more broken than any other network fs protocol.  The slowdown
happens with a stream of WRITE requests and replies.  If the requests
weren't acknowledged, there wouldn't be any trouble, but
acknowledgements do make sense for synchronous operation.

You could probably design a protocol that weren't prone to this sort
of problem, but likely that would make it more complex.

Miklos