Question performnace of SSH v1 vs SSH v2

[Michael A Stevens]

On Tue, 1 Mar 2005, Rick Jones wrote:

> Michael A Stevens wrote:
>> There is also another subtle issue of how often should the window be 
>> polled. Polling the tcp window on a WINDOW_ADJUST message could prove to 
>> be costly if they happen very often.
>
> At the very real risk of rapdily showing my ignornace of what is implied in 
> the receipt of a WINDOW_ADJUST message...

The WINDOW_ADJUST messages of SSH that is. Actually I meant to say upon 
sending of a WINDOW_ADJUST the TCP buffer should be polled. This is so you 
can adjust the window the sender has to send you data so that they are not 
limited by SSH, but by TCP.

>
> The TCP window - or rather, what gets reported in a 
> getsockopt([SO_RCVBUF|SO_SNDBUF]) - will not change during the life of a TCP 
> connection unless the application makes a corresponding 
> setsockopt([SO_RCVBUF|SO_SNDBUF]) call.  So once after the  connection is 
> established should suffice.  Again after any setsockopt call.  The reason

As Chris mentioned autotuning stacks break this assumption, but even more 
so, if a general case of the window size changing can be dealt with in 
such a simple way as to poll it from time to time, then there really isn't 
much of a reason to not do it.

> And, if the remote makes a setsockopt() call, there is no (portable) way to 
> get the remote's advertised window anyway - we can only see what our socket 
> buffer sizes happen to be.

The TCP stack handles the sending of packets to a system so it does not 
send packets outside of the window. In the same way SSH2 doesn't send 
packets outside of the SSH window. There really isn't a need to know what 
the remote host's TCP window is, its just if that host wants to make use 
of its receive bandwidth, it needs to adjust its SSH2 window to match its TCP 
window.

>
> rick jones
>
> BTW, unless the stack has negotiated window scaling when the TCP connection 
> was established (wscale on the SYN segments), there will be a hard limit on 
> the TCP window of 65535 bytes even if the socket buffer sizes are greater. 
> I've seen that _some_ stacks will use window scaling when the window is < 
> 64KB, but that is not universal.

Those are exactly the connections we are looking at here. When SCPing 
files across a 100Mbit/s coast to coast link the best performance you will 
see is around 16Mbit/s. With a 100ms RTT you can expect to hit the limits 
of the 64K window at 5Mbit/s. When you look at Gigabit links you hit 
limits of a 64K window at 0.0001 second latency.


Mike