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

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

"denis bider" <ietf-ssh%denisbider.com@localhost> writes:

>I totally agree that the SSH protocol in some places is more complicated than
>it needs to be; however, the protocol does not impede performance if properly
>implemented. 

That's the magic phrase: "If properly implemented".  The problem is that the
current design makes it extremely tricky to get good performance, borne out by
the fact that after five(?) years of existence of the spec and work on the
code, there are a large number of handbrake-enabled implementations around
with poor performance that is often noticeable enough for it to be an FAQ.

>The protocol provides you with the means to control the flow of the session,
>but it doesn't tell you how to do it efficiently. If you want to resolve
>this, the solution is to write a document describing how to use the control
>elements for best performance; not to remove them altogether. The protocol is
>fine.

I disagree, again based on the modem-protocol experience.  You can make it
simple and straightforward, with good performance, and get good
interoperability (Zmodem) or make it really hard to get right, get OK
performance if you can manage to tune it sufficiently, and get poor
interoperability because no-one can quite get it right (most of Zmodem's
successors).  The fact that I did a truly ghastly (but high-performance) SFTP
implementation in a few hours that outperformed ones that have had years of
ongoing development indicates that waiting for people to tune something that
is inherently difficult to get good performance out of isn't a viable option.

(Before people start reaching for cream pies: The point I'm trying to make
 there isn't to bash other people's software (my experimental code is
 definitely far worse than anything else out there), but to say that the
 current flow-control model is inherently difficult to get good performance
 out of, a claim that would seem to be strongly supported by the performance
 of various existing implementations).

Peter.