Dang! No HPN-SSH!

Posted Mar 8, 2010 16:57 UTC (Mon) by aaron (guest, #282)
Parent article: OpenSSH 5.4 released

I guess this happens every OpenSSH release, but I keep hoping they'll merge some of the patches from the Pittsburg Supercomputing Center.
(See http://www.psc.edu/networking/projects/hpn-ssh )
It's truly amazing how they help transfers over higher-latency links (i.e. any distance over a mile.) They also help local transfers a fair bit.
Unfortunately, for now, if you can't patch your own SSHd, you have to use commercial file-transfer software, a Riverbed, or RSA-SSHd.

Please, O pufferfish, strap on a jetpack!

Dang! No HPN-SSH!

Posted Mar 8, 2010 17:04 UTC (Mon) by alex (subscriber, #1355) [Link] (4 responses)

Is it by any chance because the OpenSSH team are worried about security
auditing code that goes from statically allocated to dynamically allocated
buffers?

Dang! No HPN-SSH!

Posted Mar 9, 2010 1:51 UTC (Tue) by BrucePerens (guest, #2510) [Link] (3 responses)

So, is the alternative to set the static buffers to 2MB?

Dang! No HPN-SSH!

Posted Mar 9, 2010 4:20 UTC (Tue) by djm (subscriber, #11651) [Link] (2 responses)

You are misinformed. There are no 2MB static buffers in OpenSSH.

Dang! No HPN-SSH!

Posted Mar 9, 2010 4:51 UTC (Tue) by BrucePerens (guest, #2510) [Link] (1 responses)

Yes, I know there are no 2MB static buffers. If you set the size of the communication buffers to 2MB, you would achieve the same speed increase as with the dynamic buffers used by the patch. That is, given a high-speed network connection. I don't know if this makes any difference for us folks with 3megabit/300kilobit DSL connections.

Dang! No HPN-SSH!

Posted Mar 9, 2010 11:04 UTC (Tue) by djm (subscriber, #11651) [Link]

The default session window in OpenSSH is 2MB already.

This limit is enough for a path with 5 seconds latency at your DSL speed.
Put differently, if your one-way path latency is 100ms then unmodified
OpenSSH's window size should only start restricting performance if your
transfer rate is ~160Mbit/s.

If you are on Internet2 and want to move files between continental USA and
Europe at gigabit speeds, then you might still want the HPN patches.

Dang! No HPN-SSH!

Posted Mar 9, 2010 4:24 UTC (Tue) by djm (subscriber, #11651) [Link] (2 responses)

We made some performance changes for high BDP links a few releases back,
which should have obviated the need for the HPN patches for all but the
highest BDP links. You should benchmark your connection to see if it
actually benefits from the HPN patches, which are quite intrusive.

The other component of the HPN patches that people sometimes ask for is the
ability to select a null cipher/MAC. We are not planning on implementing
that ever.

Dang! No HPN-SSH!

Posted Mar 9, 2010 11:51 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

Can you explain why it's a bad idea to be able to turn off secrecy? Sometimes I need to move a large file over the network, and the contents of that file are public (e.g. several TB of data published by the government). I don't care if someone sees this data, or even if they see me moving it, but I don't want anyone messing with it, thus I still need integrity. Of course I can move it with 'netcat' and then verify using sha1sum, but it'd sure be convenient if the default OS tools (ie OpenSSH) let me do this with a suitable incantation.

No-one is asking for this to be the default of course, but why can't we have it as an option without hacking the code?

Dang! No HPN-SSH!

Posted Mar 9, 2010 14:45 UTC (Tue) by andikleen (guest, #39006) [Link]

One of the main reasons for HPN is multi threaded MACing/encryption,
which is needed for fast enough links because a single core cannot do full performance otherwise.

And yes multi threading your application is typically intrusive, but
it's also very needed if it is CPU time intensive and
you want to keep up with modern systems.

Dang! No HPN-SSH!

Posted Mar 9, 2010 13:49 UTC (Tue) by andikleen (guest, #39006) [Link] (4 responses)

Fully agreed, it's really bizarre that OpenSSH is still single threaded even though cryptography takes so much CPU time. Basically you can't really use it on a serious network connection because of this problem. And in addition the small buffers also make it hard to use over a WAN.

I wonder if it's related to being developed on OpenBSD which is not exactly known for SMP scalability?

Perhaps the distros will use it some day at least, even if the maintainers can't get out of the 70ies.

Dang! No HPN-SSH!

Posted Mar 9, 2010 21:12 UTC (Tue) by djm (subscriber, #11651) [Link] (3 responses)

Yes, we are dinosaurs who would prefer to have to deal with thread race
conditions in security software. AES on my 3 year old desktop is >800Mbit/s
on a single core and RC4 is 2x faster again, so I don't think crypto
performance is a massive problem.

Dang! No HPN-SSH!

Posted Mar 9, 2010 22:25 UTC (Tue) by djm (subscriber, #11651) [Link]

err, s/prefer/prefer not/

Dang! No HPN-SSH!

Posted Mar 11, 2010 2:48 UTC (Thu) by martinfick (subscriber, #4455) [Link] (1 responses)

While I wouldn't want to tell you how to write secure software, I wouldn't dismiss the need for speed so quickly. Have you payed attention to CPU speed increases lately? A 3 year old desktop is far from a slow machine, especially for a single threaded app (since most CPU advances are simply adding cores). I run much older machines than that, 10+ years old, (as I suspect many using free operating systems do) and they do suffer greatly from encryption performance in local gigabit ssh file transfers. They also chew up over 50% of my CPU and all I care about is authentication and integrity from one machine in my basement to the other. Other non encrypted transfers are much faster on these machines and do not chew up my CPU.

Dang! No HPN-SSH!

Posted Mar 11, 2010 5:26 UTC (Thu) by dlang (guest, #313) [Link]

even on modern hardware the encryption overhead can limit transfer speeds.

on very modern system I can transfer data twice as fast over local gigE networks with HTTP or FTP than I can via SSH