IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [PATCH] Using TCP_NODELAY unconditionally



Brief summary of this thread for the IETF SECSH WG list readers:

 - two patches were contributed implementing overlapping reads/writes
   for OpenSSH's sftp client and server to improve its performance
 - the use of TCP_NODELAY was suggested
 - it turns out that OpenSSH's sftp implementation triggers the Nagle
   algorithm; this can probably be avoided, thereby avoiding the need to
   turn off Nagle on SSHv2 connections, at least in the case of SFTP

 - but what about X11? X11 normally runs over TCP with Nagle turned
   off and it stands to reason that a port forwarder ought to forward
   traffic with Nagle turned off if the traffic being forwarded
   requires that Nagle be turned off

 - which brings up the question of what the SSHv2 specs should say about
   Nagle and whether SSHv2 should have its own per-channel Nagle
   algorithm and run TCP connections with Nagle turned off

The three threads in the OpenSSH list where SFTP performance, Nagle and
X11 have been discussed are:

http://marc.theaimsgroup.com/?t=101143740600002&r=1&w=2
http://marc.theaimsgroup.com/?t=101010189400002&r=1&w=2
http://marc.theaimsgroup.com/?t=101034855100005&r=1&w=2

A quick search through the IETF SECSH WG mailing list archive yielded no
previous mention of Nagle or TCP_NODELAY.


It's not clear yet that forwarding X11 traffic with SSHv2 and Nagle
turned on is a problem. But this issue may yet come up again. So it's
probably worth addressing, even if just to state that Nagle is to remain
on at all times...

Here's some technical approaches to dealing with Nagle that I can think
of right now:

 - specify heuristics by which SSHv2 clients/servers should unilaterally
   decide to turn off Nagle. E.g., no pty sessions + X11 forwarding ->
   turn off Nagle.

 - add a global request type for requesting the remote side to turn
   Nagle off or on.

 - add a per-channel Nagle algorithm protocol, which would probably
   require new channel request message for turning the algorithm on or
   off per-channel - an acknowledgment message would also be needed, but
   gratuitous window adjustments would probably do just fine.

I'm not an expert on SSHv2. Take my comments with some salt.

Cheers,

Nico


On Mon, Jan 21, 2002 at 10:26:15AM +0100, Markus Friedl wrote:
> On Mon, Jan 21, 2002 at 10:24:28AM +0100, Markus Friedl wrote:
> > On Mon, Jan 21, 2002 at 12:41:37AM -0500, Nicolas Williams wrote:
> > > Since the protocol allows a variety of kinds of traffic to be exchanged
> > > over a TCP connection, some which should be used with Nagle, and some
> > > which shouldn't, the protocol should really be capable of implementing
> > > Nagle on a per-channel basis and always run with TCP_NODELAY, but that's
> > > a lot easier said than done.
> > 
> > ietf-ssh is the place for this.
> 
> ietf-ssh%netbsd.org@localhost
> 
--
-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.




Home | Main Index | Thread Index | Old Index