Subject: Re: Sftp: performance enhancing changes

From: [email-masked] (Peter Gutmann)
Date: Sat, 6 Sep 2003 05:56:27 +1200

Joseph Galbraith <[email-masked]> writes:

>o Ignoring channel window makes for a screaming
>  sftp transfer. (unacceptable, breaks multiplexing.)

It's only unacceptable if you're actually doing multiplexing.  If you're just
using SFTP as a secure FTP replacement (which is what many people seem to be
using it for), it's a simple, quick fix for the SFTP performance problems.

Peter.

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 05 Sep 2003 14:23:51 -0400

> using it for), it's a simple, quick fix for the SFTP performance problems.

My understanding based on reading the earlier discussion is that this
is a red herring -- the fix (which doesn't involve violating the
specs) is to pipeline read/write requests and ensure the channel
window is substantially larger than the TCP window).

					- Bill

---

From: Joseph Galbraith <[email-masked]>
Date: Fri, 05 Sep 2003 14:03:43 -0600

> using it for), it's a simple, quick fix for the SFTP performance problems.

It is unacceptable because draft-ietf-secsh-connect-17
states in section 3.2:

> The maximum amount of data allowed is the current window size.
> The window size is decremented by the amount of data sent.  Both
> parties MAY ignore all extra data sent after the allowed window is
> empty.

And our server _will_ drop data that
exceeds the channel window.

The sftp draft can't override this rule, and I
don't think we are going to change the connection
draft.

(To be honest I don't think we should either.)

Sorry, I should have been clearer on why
I thought it was unacceptable.

In addition, proper management of packet size and
channel windows can mean that there is no or very
little overhead from obeying the rules.

- Joseph

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 5 Sep 2003 17:16:53 -0700

> using it for), it's a simple, quick fix for the SFTP performance problems.

No.  The consensus of the SFTP perf thread was, IIRC, that there is no
handbrake in either SSHv2 or SFTP and that clients and servers should be
smart about using larger windows for the SFTP sub-system.

Nico

---

From: Thor Simon <[email-masked]>
Date: Fri, 5 Sep 2003 23:09:32 -0400

> smart about using larger windows for the SFTP sub-system.

There are other applications that display horrific performance characteristics
over at least some widespread SSHv2 implementations.  One notable one is
rsync.

Thor

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 6 Sep 2003 14:07:06 -0700

> over at least some widespread SSHv2 implementations.  One notable one is

This may be due to the SSHv2 client and/or server implementations
setting small window sizes for what they think is an interactive
session.  I suggest that you bring this up with the implementor, that
you try not using ptys and/or that you try making rsync a sub-system.

Nico
--

---

From: Thor Simon <[email-masked]>
Date: Sat, 6 Sep 2003 17:25:19 -0400

> session.  I suggest that you bring this up with the implementor, that

Uh, what makes you think that any common Unix implementation would use
ptys (or decide the session is interactive) when handed a remote command
to execute on the command line?  Certainly I cannot think of one that
does (this would also fly in the face of A) common sense and B) what
legacy rsh did and C) what the original F-Secure code did)).

Thor

---

From: Markus Friedl <[email-masked]>
Date: Wed, 10 Sep 2003 23:52:04 +0200

> It's only unacceptable if you're actually doing multiplexing.  If you're just

i think it's unacceptable, because it breaks the protocol.