[PATCH] Added NoDelay config option and nodelay subsystem option

[Nicolas Williams]

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)
    - turn on TCP_NODELAY for all sessions (Tobias)
    - turn on TCP_NODELAY for all sessions that have active port or
      display forwarding or which are not exec sessions (myself)

 - SSHv2 connections, longer-term:

    - add a per-channel TCP_NODELAY channel request (Markus; I second)
    - add a per-channel Nagle at the SSHv2 layer (myself, but not convinced)

Something is needed to make X11 display forwarding a happy thing and
improve SFTP performance. The latter can probably be done by coallescing
the write()s of those two packets that trigger Nagle. 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?

Nico


On Tue, Jan 29, 2002 at 09:29:37AM +0100, Tobias Ringstrom wrote:

[...]

> First of all, we only need more than one overlapping request if the
> delay-bandwidth product of the link is larger than the block size.  I do
> not have any figures for a wide number of links.  The reason why I thought
> I needed more was the interaction with the Nagle algorithm. The Nagle
> problem is orthogonal, but needs to be resolved.  It seems to be very hard
> to agree on a solution, though.

[...]

> Please reconsider the patch in light of the nodelay findings.  (And if you 
> do benchmark it, please use TCP_NODELAY in both ends.)
> 
> /Tobias
--
-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.