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

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

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
--