Linda Walsh wrote:

> BDP? ...

Bandwidth delay product. Since network transfers aren't instantaneous
there is data in transit between two hosts at any time. Any path has a
maximum amount of this outstanding data it can hold which is determined
by multiplying the bandwidth by the round trip time. If you can keep as
much data in transit as the carrying capacity of the path you end up
using the network much more efficiently. So if you have a patch with a
2MB BDP and you only have 64KB of data in transit at any time you are
only using 3% of the network capacity.

The receiving host regulates how much outstanding data there is at
anytime with the receive window. So if your receive window is 64KB then
the end host will only allow 64KB to be unACKed (or outstanding or in
transit) for each round trip time. So this end up limiting your
throughput if the BDP is greater than the receive window. As such its
important to increase the receive window to at least the same size as
the BDP.

In multiplexed applications like SSH its necessary to include an
application layer receive window. This rides on top of the underlying
TCP receive window and your effective receive window for the application
will be the minimum of the two. SSH, up until 4.7, had a 64KB receive
window. Its been boosted to ~1MB and that really helps a lot of people.
This is still small for the faster networks which is where HPN-SSH comes
in as we tie the application window to the TCP window. So as long as the
TCP window is properly sized the application window will be as well.

> One of the machines is pegged: an aging 2x1GHz PIII. It's hard to
> say what is happening where, since I'm working with 3 different machine types
> (4 if you count 1 running WinXP vs. other running Linux).

Yeah, thats a bottleneck right there. None cipher will do a lot for you.

> The file transfer speed between via scp to a a cpu-limited
> target (ish, below) is 10.4MB. The same file transfered over CIFS,
> a file-system protocol, runs at 28.7MB/s. Network tuning isn't the
> issue, though "end-to-end" latency caused by ssh may be. Someone

It may be but the amount of latency imposed tends to be small. I've not
taken the time to quantify this though.

I need to skip some stuff as I'mn giving a presentation in a few minutes
but I wanted to address a couple of ther things before I do...

> Haven't found a source for Iperf yet. But I get nearly
> 2x performance over SSH with just using SMB. I doubt disk is playing
> much of a role (note, that the 250MB file I'm xfering fits in the
> buffer cache of 3 out of 4 of the machines).

> Was preferring to have the standard ssh support it. Obviously,
> I have the sources and can hack something with-or-without a patch, but
> I don't want to get into modifying or doing a "special compile" for yet
> another piece of software (have done it with a few, and eventually I tend
> to give up my 'special mods' over simplicity).

I understand entirely.
in place.
> ----
> Well, one of the "requirements", in my proposal was to force
> the user (interactive or not) to include a switch on the ssh/scp command
> line, spelling out that encryption was turned off for the data.

In the HPN-SSH code the client must use both
-oNoneEnabled=yes and -oNoneSwitch=yes in order to use the None switch.
NoneEnabled can be set the ssh_config but NoneSwitch must come on the
command line. When it enters the NONE cipher it spits out a warning to
stderr so users are aware that the switch happened.

> I want to be able to turn off encryption on the 'normal' openssh
> product, under specific circumstances, including benchmarking to see
> what openssh's "end-to-end" latency is, but also for xfering large
> files over an internal network. While CIFS works well one one of the
> computers is Windows, It _seems_ to have lower performance between
> linux machines.

While I would like to see the None switch in the base code I'm not
entirely sure its going to happen.

> What is "HPN"...I don't recognize it as a cipher.

Its not a cipher. It stands for High Performance Networking and is a set
of modifications to improve SSH performance. Its typically geared
towards fast networks but it does have some benefits for people in your
situation. More ifnormation can be found at

Currently its being used by NASA, several governmental organizations,
its part of HP-UX, several linux distros, its available though FreeBSD,
many supercomputing centers use it, a bunch of financial institutions,
tech companies, and so forth.

Its not, in anyway, a fork of OpenSSH.

> As for "production"...
> if I wanted this at a company, I'd tend to believe I was "insane".
> "Deliberately disabling encryption at the server and client in a
> production environment"?

A lot of widely used applications do not encrypt bulk data transfers
even if they use encryption for authentication. So I'm not sure I would
say it was insane, just a different approach.
openssh-unix-dev mailing list