[PATCH] Using TCP_NODELAY unconditionally

Nicolas Williams Nicolas.Williams at ubsw.com
Wed Jan 23 02:21:17 EST 2002


On Mon, Jan 21, 2002 at 02:53:13PM -0800, Rick Jones wrote:
> > Merging the two messages into one write would make sftp not trigger the
> > Nagle algorithm, but it would not help the X11 forwarding case, which
> > really needs TCP_NODELAY.

Fortunately fixing this behaviour in OpenSSH ought not require
protocol changes.

> Indeed X11 is one of those fun fringe things when it comes to
> Nagle. It has all these pseudo-time-sensitive small messages for pesky
> things like cursor position and such that have no replies coming-back
> the other way.

Yes, so something should probably be done about X11. Or is the current
performance good enough?

> In general, I would think that if ssh were acting as a pipe, it might
> as well set TCP_NODELAY - ostensibly the applications on either end of
> the pipe are (supposed to be) doing the "right" thing with
> TCP_NODELAY. In that sense ssh should simply pass the data along since

I agree in principle. A simple heuristic, like "if an SSHv2 connection
has a no-pty session and at least one forwarded X11 channel open, then
both the client and server ought to be smart enough to set TCP_NODELAY"
would probably suffice for me. But Nagle should probably not be turned
off for interactive sessions...

In general with port forwarding you'd hope that the forwarder passes
traffic along with the same characteristics as the original. If you're
forwarding, say, CVS, and CVS uses TCP_NODELAY then the forwarder ought
to use TCP_NODELAY as well, by the your suggested principle.

But will a simple heuristic do? Or should there be a new SSHv2 global
request type for requesting TCP_NODELAY? Should there be an SSHv2
channel-level Nagle algorythm? That would require a channgel request
type to turn it on and off and an acknowledgement mechanism
(gratouitous window adjusts?) and all such talk belongs, as Markus
points out, at the IETF list.

If heuristics will do, great. It sounds like it should be simple to fix
sftp to avoid Nagle. Any other ideas that might fix X11 forwarding? Does
anyone find it necessary?

> it will have no prior knowledge (?) of the applications behaviour. The
> argument would be somewhat like the argument that says that an
> intervening router should not try to reassemable IP datagrams and
> leave that to the final recipient. (Not a perfect analogy, but it is
> what struck me at the moment.

Sounds right.

> It would seem that sftp turns what used to be a nice unidrectional
> data flow into a request/response exchange. If there is no good way to
> get thatSSH window piggy-backed with the Read then indeed setting
> TCP_NODEALY is probably required if slighly unpleasant. Sounds like
> the designers of the ssh/ssl protocl didn't keep TCP behaviour in mind
> when they were doing their thing.

You'd have to ask them...

> rick jones


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.




More information about the openssh-unix-dev mailing list