Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atO

Hi, Steve,

Steven M. Bellovin wrote:
> 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.
By essentially shutting your machine down for over an hour.

> 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.
The numbers I get are 3:1 for some protocols, worse for others, but the
CPU hit is also substantial, vs. just taking time but not CPU to do the
transfer.

> 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.
Your application shut your machine down for over an hour - just dumping
 alone wouldn't). That's substantial - sure, not for you, but you run
crypto. For those who don't, this is a large part of why (the other part
is key management, but that doesn't come into play for things like
backups since it's a single key and two known parties).

---

The point is that you have a GigE interface you don't use. Why? It's
cheap, and when you do use it - to dump at work - it's a lot faster than
100Mbps.

Crypto puts a huge dent into that capability the way it's done right
now, and nobody is selling me 1Gbps crypto chips for a price that makes
it cost-effective to put it into a laptop. And I don't exactly want to
burn 100% of my CPU capacity to saturate my 802.11 link, let alone such
a small fraction of my GigE.

Joe

signature.asc
Description: OpenPGP digital signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf