openssh unix dev - Oct 2002 - TCP_NODELAY in Cygwin port

Hello SSH developers,

I am sorry if this is not really a bug, and I am missing something, but I am
running into an issue with port forwarding in SSH.  I am using 3.4p1 of SSH on
both sides.

I am running the ssh daemon on a Slackware Linux 8.0 machine, and the ssh client
is running in Cywgin version 1.3.13.  The ssh client is creating about 7 port
forwards in a mix of local and remote forwarding
types.  Everything with this setup works great.

I have an application that runs on the linux side that port forwards to the
Cygwin side, and sends a small control packet (4-8 bytes) at a rate of 30 times
per second to an application on the Cygwin side.  Because
of this, the control application uses TCP_NODELAY in order to send it out as
soon as it can.

If I do not use SSH port forwarding, the control packets are sent at a steady
rate.  If I use the SSH port forwarding, the data is buffered, and sent in
bursts.  With this, the packets build up, so nothing is sent for 6
to 10 frames, and then all are sent at once.  This makes for jerky control.

I have looked into the OpenSSH release notes, and noticed that you added
TCP_NODELAY on your endpoints for TCP port forwarding, though it does not seem
like it is working properly.

Unfortunately, I have been unable to tell weather the burst is happening between
the sshd and the ssh, or the ssh and the application.  As I mentioned, if my
control program connects directly to the application,
no buffering is used.

Do you have any idea to why this is happening?  Is there something wrong with
the port forwarding implementation of SSH and TCP_NODELAY in Cygwin possibly?  I
ran both sides in debug mode, and it stated
that TCP_NODELAY was indeed set.  

I'm perplexed.

Thanks for your time,
Brian Genisio

On Thu, Oct 31, 2002 at 11:28:11AM -0500, Brian Genisio
wrote:
> I am sorry if this is not really a bug, and I am missing something, but I
am running into an issue with port forwarding in SSH.  I am using 3.4p1 of SSH
on both sides.
> 
> I am running the ssh daemon on a Slackware Linux 8.0 machine, and the ssh
client is running in Cywgin version 1.3.13.  The ssh client is creating about 7
port forwards in a mix of local and remote forwarding
> types.  Everything with this setup works great.
> 
> I have an application that runs on the linux side that port forwards to the
Cygwin side, and sends a small control packet (4-8 bytes) at a rate of 30 times
per second to an application on the Cygwin side.  Because
> of this, the control application uses TCP_NODELAY in order to send it out
as soon as it can.
> 
> If I do not use SSH port forwarding, the control packets are sent at a
steady rate.  If I use the SSH port forwarding, the data is buffered, and sent
in bursts.  With this, the packets build up, so nothing is sent for 6
> to 10 frames, and then all are sent at once.  This makes for jerky control.
> 
> I have looked into the OpenSSH release notes, and noticed that you added
TCP_NODELAY on your endpoints for TCP port forwarding, though it does not seem
like it is working properly.
> 
> Unfortunately, I have been unable to tell weather the burst is happening
between the sshd and the ssh, or the ssh and the application.  As I mentioned,
if my control program connects directly to the application,
> no buffering is used.
> 
> Do you have any idea to why this is happening?  Is there something wrong
with the port forwarding implementation of SSH and TCP_NODELAY in Cygwin
possibly?  I ran both sides in debug mode, and it stated
> that TCP_NODELAY was indeed set.  
i don't know.  as you can see, we call set_nodelay() for all ends of
port/x11 forwards.  i'm not really clear on where source/sink sockets
are from the above.  can you replace the cygwin piece with non-cygwin
and hence eliminate cygwin+MS TCP stack from the picture and see if
behaviour changes?  otherwise, you need to trace (tcpdump) on all ends
and determine where delays originate from.