Bulgarian mirror 10 Gbps

PuTTY semi-bug flow-control

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

(This wish applies to SSH-2; SSH-1 doesn't provide flow control above TCP's.)

As Peter Gutmann has observed, naive implementations of the SSH-2 sliding window protocol place an arbitrary limit on the throughput of each channel, limiting it to the product of the window size and the round-trip time (the so-called "SSH-2 handbrake"). PuTTY is one such naive implementation (it uses a fixed channel window size of 16k).

There are various things that could be done to work around this. In an ideal world, PuTTY would measure the bandwidth-delay product of the link it's running over and use that to set the window so as to fully use the available bandwidth without completely breaking flow control. A rather simpler approach is possible where a connection only has (and only ever will have) one channel running over it, since in that case PuTTY can open the window fully and leave flow control to TCP. This is covered by flow-control-filexfer.

Of course, things become more complicated if multiple channels were to be used (e.g., port-forwarding of bulk transfers, or some of the wilder excesses of SSH-2 generality).

As of 2007-09-25, PuTTY has much improved window handling. From the commit message:

The basic idea is that when the connection isn't being limited by our ability to process data, we want to ensure that the window size as seen by the server never drops to zero. Measuring the server's view of the window size is done by arranging for it to acknowledge every SSH_MSG_CHANNEL_WINDOW_ADJUST, or rather an SSH_MSG_CHANNEL_REQUEST [winadj@putty.projects.tartarus.org] sent just before it. That way we can tell when it its outgoing data stream it recieved the window adjustment, and thus how small the server's view of the window got.

At present, we only ever increase the window size. In theory, we could arrange to reduce it again if the server's view of it seemed to be persistently too large, but my experiments suggest that getting this right will be tricky.

Knock-on effects of this change:

• The new channel requests emitted by PuTTY as part of this change can cause a lot of noise in the logs of the OpenSSH server -- "sshd[6386]: session_input_channel_req: no session 1 req winadj@putty.projects.tartarus.org". This should be mitigated as of OpenSSH 5.1.
• The frequent new channel requests exposed a bug in the Dropbear SSH server, leading to PuTTY terminating sessions with a "Received SSH2_MSG_CHANNEL_FAILURE for nonexistent channel" message. This bug has been fixed in new versions of Dropbear (probably 0.52 onwards).

Another approach (not taken): the Pittsburgh Supercomputing Center suggest that basing the SSH window size on the TCP window size from the underlying OS can help in some circumstances. This would only be valid where the SSH and TCP connections are coterminous, with no tunnelling taking place.

If this is done, some higher-level protocols could probably benefit from similar adaptation -- notably SFTP, which since it was sped up has also used a 16k "window size" of its own for bulk transfers. We've had improvement reported from tweaking this and the SSH-2 channel window size on a 100Mbit network (ref 41A6366F.9030909@enriva.com).