----- Original Message -----
From: "Alex Samonte" <asamonteIZZATsitesmith.com>
Sent: Friday, February 16, 2001 6:27 PM
Subject: Re: [load balancing] Verisign and Load Balancers
> The new 600 card had to go to a SMP box (finally working SMP in F5's
> BSD code!). But you're still going to max out your cpu's
> and impact normal HTTP performance.
Not entirely true, the 600 card (and multiple cards) will run on the v3.x
which does not have SMP. And you're not going over the CPU's performance -
> This is a recent code fix they did. Unfortunately, the F5 itself can't
> much more than 200 conn/s anyways. The rainbow cards do not do the bulk
> encryption/decryption of packets. That's left for the general purpose
> CPU to do. At 200 conn/s the F5's cpu is pegged at 100% utilized.
There are Rainbow cards which do bulk encryption, the reason most people
don't utilize them is because the bulk encryption is generally RC4 which is,
by design, built to be fast and efficient as a software implementation -
whereas the RSA encryption used in the asymetric key exchange is fast and
efficient in straight hardware. If you look at the stages of SSL, the bulk
encryption is not difficult or processor intensive - it's essentially a
onetime pad cipher - which equates to simple substitution cipher with a
unique key at least as long as the message to avoid repitition. This is not
tough - programmatically or processor wise. That's what makes PGP such a
great system - it uses the RSA for the transmission of the onetime pad
cipher and then uses that to perform bacis substitution. Yes, I know this
is a little simplified, but its accurate enough to argue the impact of bulk
encryption on the processor. If it weren't for the asymetric key exchange -
the part everyone is off loading - SSL would have almost no impact on the
As to handling more than 200 conn/s - I've never seen an F5 box that I've
worked on or supported at more than 54% processor utilized no matter what
they were doing. Most of the real work on the BIG-IP revolves around
memory, not processor - and when compared to the other "general purpose
processors" I'd much rather have the F5's Pentium III than the ones used by
Alteon, Cisco or Foundry. Which brings us back to the SMP. With v4.0 F5
will be on the "unified" BSD kernel which will support SMP. And I'm sure
I'd rather have dual PIII 890's than anything anyone else has. I also
question the 100% processor utilization because most people will test their
SSL tps by doing nothing but flooding a box with NEW SSL sessions - NEW
sessions means NEW keys which are offloaded to the Rainbow card. I have a
hard time believing that the F5 box hits 100% utilization doing nothing buy
handing off SSL handshakes.
> And you also want it to handle all your non encrypted load balancing too.
> Not much CPU left for that.
And this again depends on what else you are doing. Is all your
non-encrypted traffic doing header parsing? That will eat up more CPU than
handling the SSL handshakes and bulk encryption - but again - the F5 has the
right processor for the job which is why their throughput doesn't degrade at
Layer 7 like most other products. RSA is off-loaded and bulk encryption is
easy - heavy header parsing or extremely complex rule-sets can and will eat
up the processor quickly - but this is an administrative issue as well. If
you write your rules correctly and plan ahead, you shouldn't need overly
> It's a serious flaw in having the SSL accelerator inline with all of
> your non SSL traffic.
No this I can agree with. Even with the F5 box there is a limit to the
amount of SSL you can handle from a pure NEW connections per second rating
on the Rainbow cards and by having them directly inline with the rest of
your site does present some scalability issues. That's why many people use
stand alone SSL (which F5 has as well) being load balanced calling back to a
load balanced VIP (I think in another message you demonstrated this in the
"one-arm" fashion - I would use a three interface BIG-IP to avoid sending
traffic accross the internal interface as many times - the same thing I do
for server-side cahces). In fact, in another life we actually had different
paths for encrypted and non-encrypted traffic. This served to keep us
mindful of what was on the wire as well.
On the other hand - how many people are doing that many NEW SSL sessions per
second? This is another of those sticky litle requirement issues that seems
to crop up. You do NOT need to support 1000 NEW SSL session/second just
because you have 1000 users using SSL. This is about as bad as the people
who use load balancing for their Internet servers and swear they need Gig
throughput - even though they only have a T1 to the Internet.
Lastly, doing the SSL at the LB puts the encryption domain as close to the
server without impacting the ability of the LB to make intelligent decisions
on encrypted as well as non-encrypted traffic. Putting SSL in front of the
LB increases the amount of time sensitive information traverses the network
in clear text. Believe it of not - this bothers some people.
P.S. I don't disagree with everything you said - that's why I picked out the
pieces. :-) Thanks for the conversation.
This archive was generated by hypermail 2b30 : Fri Feb 16 2001 - 22:28:19 EST