PuTTY semi-bug flow-control-filexfer

This is a mirror. The primary PuTTY web site can be found here.

summary: Be less clever with SSH-2 flow control in PSFTP and PSCP
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
difficulty: tricky: Needs many tuits.
priority: medium: This should be fixed one day.
fixed-in: r7679 2007-08-06

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

The full generality of this problem is addressed in flow-control. A simple 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.

As something of an aside, it might also be helpful for PuTTY to indicate somehow to the server that it only plans to use a single channel on a connection so that the server can open its window fully too. Otherwise, we only get improved download performance.

PSCP and PSFTP do both of these as of r7679, and get decent download performance.

Audit trail for this semi-bug.

If you want to comment on this web site, see the Feedback page.
(last revision of this bug record was at 2007-08-05 15:21:40 +0100)