Question performnace of SSH v1 vs SSH v2

[Christopher Rapier]

Rick Jones wrote:

> 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 being that while every other stack I have encountered in N years 
> of netperf reports back what setsockopt() asked for (modulo limits) - 
> Linux seems to report up to 2X the setsockopt() value (again modulo 
> limits).

Actually, this isn't true. The size of the TCP window can change many 
times during a tcp connection *if* an autotuning stack is being used. 
Basically, this involves a TCP MIB that monitors the connection (window 
sizes, rate, loss, rtt, and so forth) and based on that information 
adjusts the window size to maximize performance. Now, it does this on a 
per connection basis - so your interactive session to the machine in the 
room next door won't be forced to use the same 8MB buffer you need for 
your 10GigE transcontinental connection.

Its outlined at www.web100.org, www.net100.org and, as far as a I know, 
is part of the linux 2.6 kernel (but not enabled by default I think). 
Its a serious win in terms of maximizing network performance.

Since this is developed by the guys in the office next to mine I feel 
obligated to make my work compatible with theirs. Well, that and the guy 
on the 10GigE is who I'm working for. This means that we need to sample 
the tcp window size multiple times during the connection - doing it when 
a WINDOW_ADJUST is received just seemed like the best time to do it. We 
think its inevitable that this sort of autotuning will be incorporated 
into most kernels in the next few years so it makes sense to write for it.

> 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.

If there is a stack that isn't negotiating window scaling correctly then 
thats a problem outside of the scope of our work.