[PATCH] Added NoDelay config option and nodelay subsystem option

[Nicolas Williams]

On Tue, Jan 29, 2002 at 04:39:43PM +0100, Tobias Ringstrom wrote:
> On Tue, 29 Jan 2002, Nicolas Williams wrote:
> 
> > What is the current consensus?
> > 
> > Here's what I see so far:
> > 
> >  - non-SSH sockets: turn on TCP_NODELAY (all agree)
> > 
> >  - SSH connections, short term:
> > 
> >     - turn on TCP_NODELAY for interactive sessions (Markus; current state)
> 
> Which goes against all logic and theory, right?  :-)

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.

> >     - turn on TCP_NODELAY for all sessions (Tobias)
> 
> As a short time solution, yes.  An option to turn Nagle back on for 
> pty sessions (with no forwarding) would be nice.

I agree. But it's the core developers' agreement we need.

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

> >  - SSHv2 connections, longer-term:
> > 
> >     - add a per-channel TCP_NODELAY channel request (Markus; I second)
> 
> This is very nice, but can we do this without breaking the (draft) RFC?  
> Can it be done compatibly with older versions?

I think so, but empirical testing would be needed to say for sure.
This belongs in the IETF list.

> >     - add a per-channel Nagle at the SSHv2 layer (myself, but not convinced)
> 
> I'm convinced that this cannot be Nagle-like, since the Nagle algorithm i
> needs to know whether there is any outstanding data on the connection.

So? SSHv2 is a transport layer, among other things. It already has flow
control, so adding Nagle is conceptually possible - it needs a channel
request to turn it on and off and it needs a packet (SSHv2 packet, not
TCP) acknowledgement (which would be simple too since SSHv2 already runs
over a sequenced, reliable transport and so handling packets/acks out of
order is not an issue).

> > Something is needed to make X11 display forwarding a happy thing and
> > improve SFTP performance.
> 
> X11 already uses TCP_NODELAY, so that's not a problem.

I meant the SSH connection over which the forwarding is done.

> > 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.
Well, not triggering Nagle seems to me like a more noble thing to do
than just disabling it.

Di I misunderstand your analysis?

> > The former can be a trivial heuristic. All other TCP port forwarding
> > should really be done without Nagle as well.
> > 
> > What is a reasonable short-term consensus on when SSHv2 connections
> > should have TCP_NODELAY set on both sides?
> 
> This is what I'd like to know as well...
> 
> /Tobias

Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.