[PATCH] Using TCP_NODELAY unconditionally

[Rick Jones]

> You are right of course.  Thanks for straightening this out!
No problem, I have become something of a defender of the Nagle faith
:)
> This is getting funnier all the time.  The reason why the Nagle
> algorithm triggers is probably because of the
> SSH2_MSG_CHANNEL_WINDOW_ADJUST messages.  Every fourth SSH2_FXP_READ
> message, a window adjust message is sent, and the two messages are
> sent with two write calls.  Both messages are short, and one of the
> packets will be held back by the Nagle algorithm.  The window adjust
> message seems to be sent before the read message, which delays the
> read until Nagle times out, which in turn explains the bad
> performance, at least part of it.
Now you know why TCP likes to piggy-back tings like ACK's and window
updates. Not because of the nagle algorithm really, but because it
saves a separate segment :)
You description does sound like one where an app would run afoul of
the interaction between Nagle and Delayed ACK. That is assuming that
Read's have application-level ACKs and the window adjust does
not. (Does it show that I'm new to ssh protocol? :)
> Looking once more at the tcpdump, I can clearly see the Nagle algorithm 
> at work.  (48 byte is win_ad, 64 byte is sftp read request)
> 
> 22:42:47.141152 boris.ssh > igor.32784: P 17776:17824(48) ack 1439097 win 63712 <nop,nop,timestamp 1258913 309706> (DF) [tos 0x8] 
> 22:42:47.171611 igor.32784 > boris.ssh: . ack 17824 win 10880 <nop,nop,timestamp 309710 1258913> (DF) [tos 0x8] 
I'me guessing that igor is running with something like a 50
millisecond standalone ACK timer?
> 22:42:47.171773 boris.ssh > igor.32784: P 17824:17888(64) ack 1439097 win 63712 <nop,nop,timestamp 1258916 309710> (DF) [tos 0x8] 
> 
> 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.
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.
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
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.
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.
rick jones