Performance Degradation Through VPN

[Sandy Harris]

Lowell Hanson wrote:
 
> The following URL points to some throughput testing ...

There's some performance info for Linux FreeS/WAN on the web:

http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/performance.html

I've recently added a section to that document which is not yet in the web
version. 

It should be taken with some salt. I invented the estimation method as
I went along and our developers have not yet reviewed it.

It reads:

Estimating CPU overheads

We can come up with a formula that roughly relates CPU speed to the rate of
IPsec processing possible. It is far from exact, but should be usable as a
first approximation. 

An analysis of authentication overheads for high-speed networks, including
some tests using FreeS/WAN, is on the NAI Labs site. In particular, see figure
3 in this PDF document. Their estimates of overheads, measured in Pentium II
cycles per byte processed are:

                               IPsec  authentication  encryption  cycles per byte
 Linux IP stack alone          no     no              no           5
 IPsec without crypto          yes    no              no          11
 IPsec, authentication only    yes    SHA-1           no          24
 IPsec with encryption         yes    yes             yes         not tested

Overheads for IPsec with encryption were not tested in the NAI work, but
Antoon Bosselaers' web page gives cost for his optimised Triple DES
implementation as 928 Pentium cycles per block, or 116 per byte.

Adding that to the 24 above, we get 140 cycles per byte for IPsec with encryption. 

At N cycles per byte, an N megahertz machine can handle a megabyte -- 8 megabits
-- per second. If our estimate of 140 cycles per byte is correct, then to
staturate a link with capacity C megabits per second, you need a machine
running at C * 140/8 = C * 17.5 MHz. 

However, that estimate is not precise. It ignores the differences between: 

    NAI's test packets and real traffic 
    NAI's Pentium II cycles, Bosselaers' Pentium cycles, and your machine's cycles 
    different 3DES implementations 
    SHA-1 and MD5 

and does not account some overheads you will likely have: 

    firewall rules on your gateway 
    communication on the client-side interface 
    switching between multiple tunnels -- re-keying, cache reloading and so on 

so we suggest using C * 25 to get an estimate with a bit of a built-in safety
factor. For example: 

    for a 10 Mbit link, we estimate 10*25 = 250 MHz. Your old 266 MHz
        machine might do the job. 
    for a T3 (45 Mbit/second), we estimate 45*25 = 1125 MHz. You need either
       a high-end Linux box or hardware acceleration. 

Such an estimate is far from exact, but should be usable as minimum
requirement for planning. 

It matches empirical data reasonably well. For example, Metheringham's tests,
described below, show a 733 topping out between 32 and 36 Mbit/second, pushing
data as fast as it can down a 100 Mbit link. Our formula suggests you need an
800 to saturate a 32 Mbit link. The two results are consistent.

VPN is sponsored by SecurityFocus.com