This is a discussion on Re: Question performnace of SSH v1 vs SSH v2 - openssh ; 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 ...
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
> 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.
openssh-unix-dev mailing list