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

From: [email-masked] (Peter Gutmann)
Date: Fri, 11 Jul 2003 05:01:31 +1200

Markus Friedl <[email-masked]> writes:

>when multiplexing multiple ssh channels over one connection and one of the
>consumers is very slow, then the tcp flow control will not help. AFAIK, this
>is one of the reasons why there's an additional per-channel flowcontrol.

Ahh, that makes sense.  Thanks.  Still, it just shows that there are different
situations where the Ack-based flow control is appropriate, since the converse
says that when not muxing multiple channels, TCP flow control should do.
Specifically, if I'm using SFTP as just a secure FTP (without anything fancy
like SSH port forwarding, just a dumb copy), it's just an updated form of
rcp/scp: Open a connection, blast data across as quickly as possible, close
the connection, either with a successful close or an unsuccessful disconnect
on error, just as rcp does.  All I want at that point is the fastest possible
transfer, if there's a flow-control problem TCP flow control will handle it,
and if there's a fatal error then all you can do is close the session, just
like standard rcp.

Since it's situation-specific, software could either enable it when there's no
need for Ack-based flow control (e.g. the example I gave above), or when
requested by users.  As a command-line option, I think -u (for "ludicrous
speed") would be the only viable candiate (-l is taken, and so is -p for
"plaid").

Peter.

---

From: Markus Friedl <[email-masked]>
Date: Thu, 10 Jul 2003 21:57:05 +0200

> and if there's a fatal error then all you can do is close the session, just

But then all you need to do is to announce a big window size.

E.g. the client can announce big window sizes if no pty allocation
is involved.  Recent OpenSSH's do this.