ietf
[Top] [All Lists]

Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]

2007-11-14 15:33:32
On Wed, 14 Nov 2007 15:39:50 -0500
Stephen Kent <kent(_at_)bbn(_dot_)com> 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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>