[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPSec still too slow?

We all have probably suffered the custom crafted perf study - either
from competition or laymen.  I'd suggest that we (vendors at least) need
an equivalent to the web perf metrics like SPECWEB, WEBCAT, etc - a well
defined and peer-reviewed performance study technique for IPsec
transport mode client-server, and IPSec tunnel mode gw-to-gw that could
be applied across all implementations.  Could we take one of the web
metrics and define the details of the IPsec policies under it ?  I'd
think the gw-to-gw tunnel products would need something of their own.

Some Windows 2000 comments:

The scaling of hardware acceleration performance cited for Windows 2000
is partly due to how the offload NIC vendor decides to manage the
in-hardware SA state.  Windows 2000 itself will offload to hardware as
many IPsec SA pairs as the NIC driver will accept.  How the NIC driver
and it's hardware manage that state is transparent to the Win2k ipsec
driver.  Each offload vendor has a different driver<->NIC offload
design.  Each offload design will result in different performance
results on the same Win2k system.  And of course both Intel and 3Com
have "client" and "server" versions of their NICs.

Win2k dependent issues for scaling perf are the number of different
filters in the filter list, and number of active SAs, and CPU.  Of
course the application data flow across all active SAs determines how
much the host CPU is needed.  Since we idle IPsec SAs out by default at
5 minutes (configurable), scaling again depends also on the application
traffic pattern.  The implementation choice of IKE as a non-kernel mode
IPsec SA manager, combined with relative-to-data-rate short IPsec SA
lifetimes may impact scaling as well.  Certainly the choice of
encryption and hash algorithms matters.  An IPsec policy may specify
filters that are all traffic or port specific or with actions to permit,
block, or secure.  

Ultimately, this means observable perf for a deployment depends exactly
on the hw config, the IPsec policy config and the apps.

Wm
Program Manager, network security, IPsec
Windows OS Division

-----Original Message-----
From: Natalie Timms [mailto:ntimms@cisco.com] 
Sent: Saturday, October 06, 2001 3:30 PM
To: Alex Alten; Joel M Snyder; ipsec@lists.tislabs.com
Subject: RE: IPSec still too slow?


I just wanted to let you all know (sorry to those not particularly
interested), that the Cisco 7140 numbers are inaccurate due to a
miss-configuration of the device. The 42 Mb/sec quoted is less than half
of what this device is capable of. Although this much throughput running
process switching only actually rocks, its not what we'd be recommending
to customers!

In our own internal testing we've found that raw throughput tests are
somewhat meaningless as they are not indicative of the real world. It
would be great to see stats based on other things running on the box -
firewalling, NAT, keepalives, routing, etc.....

-Natalie






At 09:25 PM 10/5/2001 -0700, Alex Alten wrote:

>Joel are you willing to post all the raw test results to the IPSEC 
>mailing list?  It's really hard to understand what the numbers really 
>mean in your article.  I for one wouldn't mind if you change 
>vendor/product names to something like vendor A/product X (although 
>some indication of processor speed would help here).
>
>What I'm looking for is raw throughput (various packet sizes), latency 
>(SA
>setup costs), error rates (%dropped packets, lost fragments), timing
delays.
>
>BTW, did you test with various legacy protocol/apps?  For example did 
>anything break if they didn't get the expected TCP segement handed to 
>them in the app layer?
>
>- Alex
>
>
>At 05:20 PM 10/5/2001 -0700, Joel M Snyder wrote:
>>Alex has misinterpreted what I wrote.  The performance drop I
>>saw was exclusively with the Microsoft implementation.  I only
>>brought that statistic out because they have such incredibly good
>>performance (with $90 Intel NICs) with small numbers of SAs.  
>>
>>I did not test all the products in that review with hundreds of SAs, 
>>but I have tested Cisco, Nokia, and Netscreen and seen negligible 
>>performance degradation as the size of the SPD/SAD tables get large.  
>>In this case, I think that we're seeing an implementation issue with 
>>the card---it's just not designed to handle hundreds of SAs (on the 
>>other hand, it costs less than $100, so it's really an incredible 
>>solution for some branch office environments).
>>
>>In general, IPSEC performance in labs looks great because we don't 
>>cause fragmentation.  When fragmentation rears its ugly head, 
>>performance can go to hell (or even cause connectivity failure) very 
>>quickly. Or not, depending on the design of your application.  
>>Encryption performance is generally not the problem.
>>
>>I do get pissed off at people who throw around latency claims, though.

>>One major firewall vendor (who should remain nameless) claims that one

>>of the big advantages of co-locating the IPSEC and firewall function 
>>inside of the same box is that two boxes add too much latency.  In the

>>lab, even with the slowest and stupidest of VPN products, I rarely see

>>more than 1ms latency---completely indistinguishable across the 
>>general purpose Internet.
>>
>>http://www.nwfusion.com/reviews/2001/1001rev.html
>>
>>jms
>>
>>
>>Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
>>Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX)  
>>jms@Opus1.COM    http://www.opus1.com/jms    Opus One
>>
>--
>
>Alex Alten
>Alten@Home.Com
>
>***********************
>* Just Say NO to RC4. *
>***********************

------------------------------------------------------------------------
--------------
Natalie Timms			Ph Office : 408 527 5114

Technical Leader 		             Email : ntimms@cisco.com
Strategic VPN Projects 
VSEC BU				Pager : 1 800 365 4578 or
Cisco Systems			ntimms@epage.cisco.com
------------------------------------------------------------------------
---------------