Bug#693424: ssh: Please include HPN (high performance networking) patches for SSH

[Peter Samuelson <peters@p12n.org>]

[Colin Watson]
> Sorry, but I am not going to include any more large and invasive patch
> sets in Debian's OpenSSH package, especially not ones that add new
> configuration options (upstream has a history of giving such things
> different names when they accept them, and then I'm stuck maintaining
> configuration file compatibility forever).  This needs to go upstream.

Understandable, but too bad.  Apparently this dramatic performance
improvement is unlikely to go upstream:

    "So if HPN-SSH is so awesome why hasn't OpenSSH adopted it? That's
    a long story and people who know the OpenBSD team probably already
    know the answer.  I understand many of their reasons - it's a big
    patch which would require additional work on their end (and they
    are a small team), they don't care as much about performance as
    security (though there is no security implications to HPN-SSH), etc
    etc etc.  However, even though OpenSSH doesn't use HPN-SSH Facebook
    does.  So do Google, Yahoo, Apple, most ever large research data
    center, NASA, NOAA, the government, the military, and most
    financial institutions.  It's pretty well vetted at this point."

        - http://stackoverflow.com/questions/8849240

My own 2c: the NONE cipher and the parallel AES implementation are not
very interesting, because with an Intel Sandy Bridge CPU (with hardware
acceleration for both AES and GCM), the AES + GCM mode ciphers are
_really_ fast.  Anyone who cares about performance should be using
them, and should buy Sandy Bridge or newer CPUs.

But the receive buffer scaling part of the HPN patchset is still
relevant, and in fact quite critical for long fat pipes.  (Fortunately
the various features are broken out into individual patches.)  I wonder
how long until OpenSSH upstream realises that a 1.2 MB window is not
really large enough on today's Internet.