[NOTE: Cross-posted to two OSo lists. Please reply only to the relevant
lists.]
A customer expresses interest in the HPN-SSH patches[0].
This has come up before, of course, and this is my response (but I'm not
responsible for SunSSH nowadays):
- Dynamic windows is an obvious, good improvement;
- Async I/O in SFTP (which is not part of the HPN-SSH bundle, but which
the protocol is designed for) would be very good too;
By this I mean that SFTP, being more a filesystem protocol than a
file transfer protocol, allows multiple extant reads and writes to
random file offsets, and we could take advantage of this by using
aio_read(). I.e., when uploading files the client could run a tight
loop doing aio_read()s and when the reads complete send corresponding
SSH_FXP_WRITE packets -- these may be completely out of order, of
course. And when downloading the client should run a tight loop
sending SSH_FXP_READ packets, which the server should respond to by
calling aio_read() and then sending the SSH_FXP_DATA when the read
completes. Writes, being buffered, are already asynchronous, so
aio_write() shouldn't be needed here. The end result should be that
the sender should be able to saturate disk and network I/O by not
blocking on reads, but it does presume dynamic windows, and TCP
buffer [auto-]tuning (see below). Note that there is no need to wait
for SSH_FXP_STATUS/DATA replies to WRITE/READ requests before sending
the next one.
but
- The none cipher is controversial;
- And the multi-threaded counter mode ciphers are great, except that
that should fit correctly into the Solaris architecture -- no knob
should be needed to make that available, and no more threads should
be used than would actually speed up performance, which means the
code has to be self-tuning;
The customer agrees that counter mode parallelization should be
automatic and hidden by the Solaris cryptographic framework. On a T2
system, for example, I suspect that multi-threading AES counter modes
would be a loss, but I suspect that on a T1 it would be a win. Users
shouldn't have to think about this at all. Yes, this implies that
SunSSH should be using PKCS#11 (or the OpenSSL PKCS#11 engine).
Getting SunSSH to do so, and getting the Solaris crypto framework to
intelligently parallelize counter modes, both, will probably take a
while.
- Setting the TCP socket buffer size should also be something that
applications shouldn't have to do, but so far we don't have
auto-tuning of TCP buffer sizes. Exposing these new ssh knobs could
complicate efforts in this direction, but then, that's just intuition
on my part (though in any case making users have to think about
buffer sizes on the client and server sides in order to get
high-performance strikes me as not user-friendly).
The customer agrees that having to set client- and server-side buffer
size options is not at all user-friendly.
Question for networking-discuss:
Is there an OpenSolaris project to auto-tune TCP send/receive buffer
sizes? If so, what is its status? Certainly there exist TCP buffer
size auto-tuning efforts outside OpenSolaris, such as [1] (among many
others).
Questions for security-discuss:
Is there any project to parallelize parallelizable cipher modes where
it makes sense?
Do we want to provide an option for the 'none' SSHv2 cipher?
Thanks,
Nico
[0] http://www.psc.edu/networking/projects/hpn-ssh/
[1]
http://www.freebsd.org/news/status/report-oct-2006-dec-2006.html#Automatic-TCP-Send-and-Receive-Socket-Buffer-Sizing
