CentOS - Feb 2011 - OpenSSH could be faster...then why don't they path it??

https://www.psc.edu/networking/projects/hpn-ssh/hpn-v-ssh-tput.jpg
 
 "SCP and the underlying SSH2 protocol implementation in OpenSSH is network
performance limited by statically defined internal flow control buffers. These
buffers often end up acting as a bottleneck for network throughput of SCP,
especially on long and high bandwith network links. Modifying the ssh code to
allow the buffers to be defined at run time eliminates this bottleneck. We have
created a patch that will remove the bottlenecks in OpenSSH and is fully
interoperable with other servers and clients. In addition HPN clients will be
able to download faster from non HPN servers, and HPN servers will be able to
receive uploads faster from non HPN clients. However, the host receiving the
data must have a properly tuned TCP/IP stack."
 
 My question is: So Why Does the original OpenSSH has "limited statically
defined internal flow control buffers"?? It could be way faster, even 10x!!
 
 With the HPN-SCP path it could be the descendant of FTP! Why aren't there
any ""OpenSCP packages""? ('normal SCP+HPN-SCP path+no
local user needed for SCP'ing+chroot by default')
 
 Any opinions?
 
 Thank you!


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos/attachments/20110206/a240410a/attachment-0001.html>

On Sun, Feb 6, 2011 at 7:20 AM, kellyremo <kellyremo at zoho.com>
wrote:
>
> https://www.psc.edu/networking/projects/hpn-ssh/hpn-v-ssh-tput.jpg
>
> "SCP and the underlying SSH2 protocol implementation in OpenSSH is
network
> performance limited by statically defined internal flow control buffers.
> These buffers often end up acting as a bottleneck for network throughput of
> SCP, especially on long and high bandwith network links. Modifying the ssh
> code to allow the buffers to be defined at run time eliminates this
> bottleneck. We have created a patch that will remove the bottlenecks in
> OpenSSH and is fully interoperable with other servers and clients. In
> addition HPN clients will be able to download faster from non HPN servers,
> and HPN servers will be able to receive uploads faster from non HPN
clients.
> However, the host receiving the data must have a properly tuned TCP/IP
> stack."
>
> My question is: So Why Does the original OpenSSH has "limited
statically
> defined internal flow control buffers"?? It could be way faster, even
10x!!
>
They are likely erring on the side of safety. Dynamic buffers could
introduce some vulnerabilities. You can generate race conditions in
different ways, and whenever there's a dynamic run-time setting this
increases the exposure surface.

BTW, at the end of the linked article:
ms with buffer_append_space in HPN-SSH. If you are experiencing
disconnects due to a failure in buffer_append_space please let us
know. We're currently tracking some problems with this and we're
trying to gather more information to help resolve it.


> With the HPN-SCP path it could be the descendant of FTP! Why aren't
there
> any ""OpenSCP packages""? ('normal SCP+HPN-SCP
path+no local user needed for
> SCP'ing+chroot by default')
>
> Any opinions?
>
> Thank you!
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
>

Kellyremo wrote on Sun, 06 Feb 2011 04:20:40 -0800:
> Any opinions?
Yes. Please carry it to the appropriate forum. Thanks.

Kai

On Sun, Feb 6, 2011 at 7:20 AM, kellyremo <kellyremo at zoho.com> wrote:
> My question is: So Why Does the original OpenSSH has "limited
statically
> defined internal flow control buffers"?? It could be way faster, even
10x!!
> Any opinions?
>
> Thank you!
I think this thread would be very welcome on the comp.securty.ssh
newsgroup, also available as a Google group. It's been dull over
there, and as an old-time poster there, I think it would be a welcome
discussion.

More generally and for CentOS, this software has an *old* core, and
its stability is critical. There are a lot of recent computational
capabilities that weren't envisioned when it was written, and "Keep It
Simple, Stupid" remains critical to this and other system utilities
that have to run as trusted, critical services without updating every
few weeks as the last round of changes introduces new or rediscovers
old bugs. Like bind and sendmail and ftp, it doesn't need new features
that often, and the software *must be* compatible with older clients
and servers. If you want leading edge features, hop over to Fedora to
test and refine it, then encourage its backport to RHEL and CentOS.