IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



If someone wants to experiment, feel free to take a look at the SKERMIT (Secure shell Kermit) subsystem which is available for use with OpenSSH.

  http://www.kermit-project.org/skermit.html

This is simply C-Kermit 8.0 running as an SSH subsystem just like SFTP. You can control from the C-Kermit or Kermit 95 client whether or not you wish to use Streaming Kermit transfers (the default) or traditional Sliding-windows Kermit with slow start. When slow start is used the packet size starts small and grows to the maximum implemented 9024 bytes (Kermit protocol allows packets up to 866,304 bytes but no one has ever required it.)

It might give you a better idea of the performance characters.

Jeffrey Altman



Nicolas Williams wrote:

On Tue, Jul 08, 2003 at 04:01:02PM +1200, Peter Gutmann wrote:

[...]

Good write up!

Implementations could start with small SECSH channel window sizes and
grow them as needed so as to maximize throughout without creating
bottlenecks.  A slow-start for SSHv2, so to speak.

Consider an implementation such as OpenSSH where the SECSH protocol and
the SFTP protocol are implemented in separate processes communicating
over IPC.  With such an implementation one might, in some situations,
end up having a bottleneck in the IPC connection, rather than in the
client-server TCP connection, and under such circumstances one might
like the SECSH channel flow control mechanism to work as advertised.

But when there is no bottleneck flow control does become a "handbrake."

And I've already pointed out that SFTP has no Ack handbrake.


-- Snip --

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.  Currently the spec describes
a rather messy mechanism where both sides start by shouting at each other and
then engage in a complex dance to sort out what's what afterwards (the
"guessing" stuff).  This leads to really messy implementations when one of the
partners doesn't get the dance steps right.


I don't think the optimistic key exchange concept is difficult to
implement.  I am, however, bothered that only one kex attempt can be
made per-connection (whereas many authentication attempts can be made
per-connection).

I also think that the kex negotiation is a bit clumsy in some ways - see
the recent threads started by Joel N. Webber II.

On the other hand, the key exchange negotiation part of the protocol and
how it factors into the session ID generation is a crucial aspect of the
protocol's security, and so keeping it simple/stupid is actually quite a
reasonable thing to do.


There is no good reason for this complication in the protocol.  I don't buy
the RTT argument given in the SSH-transport draft, the guessing stuff saves
one whole RTT, but then the incredibly chatty authentication protocol ("Would
you like to authenticate then?" - "Yes I'd like to authenticate" - "How would
you like to authenticate?" - "Well, would the following suit you?" - "That
looks about right, let's do it" - "Right, I'm about to start" - etc etc etc)
more than makes up for any miniscule savings during the initial handshake.

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.


We've recently seen that exchanging lists of algorithms is not good
enough.


That removes all of the handshake-dance complexity, and vastly simplifies
implementations.


Of course, it's really too late to consider modifying the key exchange
protocol.  Perhaps for version 2.1 of the protocol...

Cheers,

Nico




Home | Main Index | Thread Index | Old Index