On Wed, 14 Nov 2007 15:39:50 -0500
Stephen Kent <[EMAIL PROTECTED]> wrote:
> Joe,
>
> I disagree with your suggestion "The software performance of security
> protocols has been the more substantial issue, and is likely to
> continue to be for the forseeable future."
>
> I suspect that most desktop users do not need hardware crypto for
> performance. Irarely if ever drive my GiGE interface at its line
> rate. With fast processors, especially multi-core processors, we have
> enough cycles to do symmetric crypto at data rates consistent with
> most application demands for individual users. Public key operations
> for key management are usually low duty cycle, so they too can be
> accommodated.
>
Thanks -- I was going to say something similar. I regularly back up my
laptop's disk over a software-encrypted GigE link. The dump file
occupies about 35G of disk space; it takes about 70 minutes. Exclusive
of protocol overhead, that comes to ~71M bps; given IP, TCP, and ssh,
I'd guess it's more like 75-80M bps. I also know that I can run ttcp
between that pair of machines at about 500M bps. Am I really suffering
from a 7:1 performance hit from the crypto? Nope.
I can't do controlled experiments right now, since the laptop and
server in question are currently about 350 km apart at the moment.
Dumping the disk to /dev/null took about 30 minutes. The maximum hit
I'm taking from the crypto, then, is about 2.3:1. Using the
performance numbers from 'openssl speed' for 1024-byte blocks for
AES-128 and SHA-1, the crypto is 23 minutes of CPU time. (This is a
1.8Ghz, single-core laptop.) The other 17 minutes probably go to data
copies -- I'm doing 'dump | ssh cat >file' -- so a kernel implementation
(say, IPsec) would be better -- and overhead, plus (of course)
calculation error). The point, though, is that the crypto isn't the
limiting factor. It's not stopping me from doing anything. It's not
even the biggest bottleneck in my application. And *that's* what's
important -- not *network* speed, but *application* speed.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
