Re: Why SFTP performance sucks, and how to fix it

[Simon Tatham <anakin%pobox.com@localhost>]

Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote:
> The SSH-level handbrake can therefore be provisionally removed by
> having implementations set the window size to INT_MAX, and
> permanently removed by deprecating the Ack/window-based flow control
> and perhaps optionally providing Xon/Xoff-style flow control if
> absolutely necessary (as was mentioned earlier, both SSHv1 and
> SSL/TLS function fine without requiring this).  The SFTP-level
> handbrake can be removed by eliminating the maximum packet-size
> wording of the SFTP specification, and recommending that
> implementations read and write all data at once rather than engaging
> in additional redundant packetisation at the SFTP level.

I'm unconvinced by this, since what you're throwing away here is
error reporting and controllability. The useful effect of breaking
down reads and writes into individual packets is that you get back
intermediate success and failure reports from each one.

If the server suddenly stops accepting data half way through writing
a 200Mb file - perhaps the disk has filled up - then ideally you
want that information communicated back to the client in a timely
manner, and not to already be committed to spewing another 100Mb of
data down a network connection whose other end can do nothing useful
with it. Similarly, if _your_ disk fills up half way through
receiving a 200Mb file, you want to be able to ask the server to
stop sending you data you can't use. This is a _problem_ with SCP,
which SFTP has fixed; don't throw out the baby with the bathwater.

I still think a better solution to the SFTP-level `handbrake' would
be to use the Kermit approach: simply queue k multiple requests at a
time, and every time the nth ack comes in, submit the (n+k)th data
packet. Adjust k appropriately (my vague plan is to stop sending
data packets as soon as my TCP layer reports that sent data is being
queued locally). This is what I plan to do to PSFTP in the
reasonably near future.

At the SSH level: I'm sure I remember trying to set packet sizes to
INT_MAX in an early version of PuTTY. This did cause me trouble,
although I don't recall the precise details. I wouldn't be too
surprised, though, if some implementation tried to allocate a buffer
the size of the window, to avoid fiddly memory allocations going on
all the time during channel operation. In which case your `ignore
window adjusts and send as fast as you can' strategy might well run
into trouble!

As Markus observes, the per-channel windows are vital for
flow-controlling multiplexed connections running at different rates,
so I doubt _unconditionally_ upping window sizes would be a useful
change to a general SSH implementation. I might give it a try in
PSFTP and PSCP only, however, and see if anyone's implementation
still barfs on the idea of a window that big.

Do you have any way to fix the SSH level for SFTP uploads? An SSH
client which knows it's being used for SFTP can change its own
maximum window size, so that the server can send arbitrary
quantities of data with no constraint beyond the TCP-level acks. But
for uploading, you'd have to persuade the SSH _server_ to change its
window size depending on the use the client planned to put the
connection to. (Having the server unconditionally set all window
sizes to INT_MAX is a silly idea, for multiplexing reasons.)

> While I'm pointing out things that should be fixed in the spec, my
> other big gripe is the way the initial message is handled.
[...]
> The way to fix this is simple: Replace all the guessing stuff and
> the complex rules that go with it with:
> 
>   Key exchange begins by each side sending lists of supported
>   algorithms.  The server sends its list of supported algorithms
>   first, the client chooses which ones it prefers that it also
>   supports and sends back its choice in the reply.

Well, no problem there. All you have to do to get this fixed is to
point it out three years ago, _before_ the draft RFCs were in last
call and a large number of fairly polished implementation existed! :-)
-- 
Simon Tatham         "Every person has a thinking part that wonders what
<anakin%pobox.com@localhost>    the part that isn't thinking isn't thinking about."