[PATCH] Using TCP_NODELAY unconditionally

Rick Jones rick_jones2 at hp.com
Wed Jan 23 06:37:54 EST 2002


Nicolas Williams wrote:
> 
> So you're arguing against channel-level Nagle in SSHv2? Is it too
> complex?

I guess what I am driving at is that unless there are gratuitous things
being done by SSH to further break-up the data it is forwarding, setting
TCP_NODELAY will "preserve" the on-the-wire appearance of the
applications at either end. It does not matter if they set TCP_NODELAY
or if they did not.

If the app did not set TCP_NODELAY, its first small send will arrive at
ssh's socket, and ssh will send that along (yes?). The ACK from the ssh
host will be sent back to the app's TCP, and the rest of the small sends
will be send and will arrive and ostensibly be recieved in one swell
foop by ssh (it does use a reasonably large recv buffer yes?) and then
will be passed-along by ssh on the other side.

If the app _did_ set TCP_NODELAY, all the small sends will start
arriving, and it will be a race between SSH and the remote. If ssh is
faster than the remote, then the sends ssh makes out the other side will
also be small, just like the app did originally. If SSH is not quite as
fast, those little sends will accumulate in the socket buffer and ssh
will then read larger chunks and presumeably send larger chunks out the
other side.

So, from that standpoint, any loss of interactive responsiveness in
something like say X11 may be caused as much by ssh not being as fast as
the endpoint(s) and chunking those mouse events as a result. From the
standpoint of the network and a network purist, this is perhaps actualy
a _good_ thing :) However, it is not good enough that I would ask that
ssh try to make this explicitly happen.

Now, when SSH _does_ get a big chunk of data from one side, if that has
to become several ssh "messages" (I'm assuming that ssh in essense
introduces message boundaries thanks to the encryption?) that those
several ssh "messages" be presented to the transport in one send call
(perhaps writev or sendmsg). To do otherwise I would _probably_ call a
gratuitous breaking-up of the data it received to be passed-along.

rick jones
-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...



More information about the openssh-unix-dev mailing list