Optional 'test' or benchmark cipher

[Chris Rapier]

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

http://dast.nlanr.net/Projects/Iperf

> 	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
http://www.psc.edu/networking/projects/hpn-ssh

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.