Multi-threaded OpenSSH

Yes, TCP flow control is a big, big problem for high-speed links.  For a (commercial but)
quantitative analysis, see http://asperasoft.com/technology/problem/.

It turns out packet loss rate is a poor way to measure congestion on wide-area links, where
there are many causes of packet loss other than congestion.  Fortunately, better measures are
known now.  In places where there's money to spend (particularly e.g. movie & music studios,
lately, but increasingly in military and oil exploration) most data goes via non-TCP
protocols.  For example, all the studios copy music files to iTunes download servers via the
FASP flow control method mentioned in the link above, implemented at user-level on top of UDP,
using ordinary PCs running Linux, Windows, or Macosix.

As I understand it, AES is faster than Blowfish, and is also implemented in every current SSH
server.  Have you benched Blowfish against AES?  AES has the further advantage of having been
vetted by every group of top world cryptographers.   OpenSSH (at least as shipped in Debian)
defaults to aes-128-cbc.  If you don't trust AES 128, you can edit /etc/ssh/ssh_config to
prefer AES 192, and probably still encrypt faster than blowfish.

A modern CPU can encrypt fast enough to saturate a several-hundred-megabit link.  For most of
us, the CPU is not the bottleneck.

Triple DES aka 3DES is only the default for SSH protocol version 1. You should not still be
using version 1 unless you are somehow unable to upgrade (e.g. device is physically
inaccessible, and has no firmware upgrade capability). Version 2 fixes important design
mistakes which have potential security implications.

When using version 2 clients and servers do negotiate, and the default between two OpenSSH
implementations is AES. AES was chosen because it is standard, and it became standard because
it is fast yet strong - Rijndael was the product of an experienced cryptographic team whose
earlier ciphers had proved well designed. During the main AES process all the participating
teams did extensive cryptanalysis of their own and each others ciphers, no serious problems
were identified in any cipher. Rijndael was eventually chosen over Twofish (a blowfish
successor) and three other contenders to become AES.

Blowfish is probably (I haven't tested) faster than AES, at least on some hardware, but not
enough to justify the small yet not at all imaginary uncertainty concerning its strength. Why
risk using something other than AES if you're going to bother using all those CPU cycles to
encrypt something at all ?

As others have mentioned, the default for modern ssh is AES, not 3DES.  Contrary to some
suggestions in this thread, Blowfish is in fact slower than AES:

$ time scp localhost:/tmp/test /dev/null
test                                       100% 1000MB  45.5MB/s   00:22    
scp localhost:/tmp/test /dev/null  17.14s user 2.39s system 81% cpu 24.097 total
$ time scp -c blowfish localhost:/tmp/test /dev/null
test                                       100% 1000MB  41.7MB/s   00:24    
scp -c blowfish localhost:/tmp/test /dev/null  21.29s user 2.17s system 88% cpu 26.625 total

So adding -c blowfish to the command line costs ~20% cpu on the client (and something similar
on the server, presumably), and ~8% in throughput (I guess because this test was partially
disk-bound).  This is with a Core2 cpu.

What's the problem with using rsync? You can authenticate using your ssh keys and the transfer
is unencrypted.

That patch exists, from the same people at PSU, IIRC. Grep the openssh dev mailing-list.