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

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

Martin Pool <mbp%samba.org@localhost> writes:

>Of course I agree that 4k or even 32k is too small for most modern networks.
>But I did want to point out that going too far in the opposite direction can
>be a problem too.

Fair enough.  I guess the XON/XOFF thing (to replace the Ack) would do this,
or perhaps a channel close depending on the seriousness of the error.  I think
it'd need some experimentation/going through usage cases to see where/how it's
useful:

- Typical usage: SSHv1 and SSL/TLS don't seem to need any flow control, which
  would imply that in most cases you don't have to worry about it.

- Out of disk space: Probably a channel close, since it's a fatal error and
  you want the sender to stop permanently ("Please wait while the sysadmin
  hot-plugs some more RAID storage" probably won't work :-).

- Temporary resource problem (can't think of a good example at the moment but
  I'm sure there's something): Send XOFF, perhaps with an optional timeout
  indication, if the sender doesn't get an XON in that time they can consider
  it a long-term/fatal error as above.

Another thing to keep in mind here is that if you signal a read/write of the
entire file at once, the receiver knows how much disk space it needs and can
lock the space before starting the receive - it allows far better data
transfer management then sending an arbitrary number of tiny little bits that
the receiver has to take care of on the fly.  I'd really prefer to know before
I start that a transfer is going to fail, rather than write 2GB and then get
the out-of-disk error.

If you follow this stragegy you never need to signal out-of-disk during a
transfer, only at the start.  Even better would be to require (or at least
recommend) that clients include the file size in the FXP_OPEN *before* any
data transfer is about to take place, so the receiver can respond to the open
request with not-enough-disk-space error.  This is perfectly feasible in most
cases where SFTP is used, since you're sending files of a known size (I
haven't played with this too much, but it doesn't appear that implementations
indicate the size at open much, which would require a code update).  You can
really optimise the transfer management by following a few simple rules in
which the sender transmits information required to ease data processing in
advance.

If it's of any use to people, I could write a small informational appendix or
whatever for the draft indicating how to use the protocol in a manner that
makes data transfer management easier.

Peter.