Jeffrey D. Smith wrote:
Greetings,
An interesting thread that seems to be based on offloading
CPU cycles from the main processor onto the device controller.
I remember similar discussions many years ago regarding data
compression when the CMPSC instruction was introduced.
"Why didn't IBM put the compression into the DASD/TAPE/whatever
controller thing?"
We did, as I'm sure you know, some time ago. In my opinion the
market reacted as it did, by buying lots and lots of drives with
compression, because offloading that work is economical and
offers better performance than not offloading it.
Controller-based compression/encryption may be reasonable in
some situations. I prefer CPU-based compression/encryption mostly
for the extreme flexibility in exploiting the feature.
We have both now; use whichever you'd like. But there are some
tradeoffs...
I must admit that I am prejudiced towards CPU machine instructions.
I would much rather have compression and encryption available on
the CPU instead of outside the CPU. I would rather see faster I/O
devices without compression/encryption.
How about faster I/O devices *with* compression/encryption?
(Sorry, couldn't resist.)
I have several (admittedly self-serving) reasons:
1. CPU-based compression and encryption means a market niche for
software products that can utilize those features, wrap a nice
user interface around it, and provide flexibility for future
enhancements. Ciphering the data in main storage gives me the
choice of when and where to cipher. Encrypted data in main storage
can be delivered to/from DASD or TAPE or TCP/IP or whatever. A
"Tape only" encryption solution greatly limits my choices.
Well, we have both. But consider that in-controller compression
speeds up the effective tape I/O rates considerably (typically 2X
or more). I recall that it was once true that multiplying the
tape transport speed by the recording density exceeded the
channel data rate (3420-8s ran 800 ips at 6250 bpi when channel
data rates were 1.5 MB/sec). Those days are gone. The
electronics are now much, much faster than the native transport
R/W speed. Encrypting in storage and writing to tape basically
disables compression, and cripples the effective I/O rate.
2.
<snip>
3. External compression/encryption may lock-in a customer to a
proprietary hardware scheme that may be difficult to reverse engineer
for migrating to another vendor's hardware.
How does this differ from tape hardware in general? New tape
formats are *always* incompatible with prior hardware generations.
4. CPU-based compression/encryption is an opportunity to decide
where to apply CPU cycles. "Should I encrypt all of my data bases
or just mission-critical?" "How do I integrate a software security
product, like IBM RACF, with this hardware thing?"
You have that opportunity whether you use CPU-based encryption or
controller-based encryption, so I'm not sure I understand why you
see this as a differentiator.
5. Off-loading CPU cycles to an external compression/encryption
thing can be attractive when the site is cycle-constrained, but
it's attacking a symptom instead of the cause. The CPACF encryption
instructions are extremely fast; they won't be the bottleneck in a
large application.
Peformance aside, what does it do to your 4-hour rolling average
MSUs when you have some CPs running 100% busy for a few hours at
a stretch to write large tape files?
From a performance standpoint, you can sustain much higher data
rates with encrypting drives than with a CPACF. (167 MB/sec per
CP at best for AES without compression, and 67 MB/sec per CP with
compression vs. the worst-case 104 MB/sec native transport speed
on the TS1120 with both compression and encryption.) Think about
running ten drives at a time vs. tying up 10 CPs at a time. The
CPACF numbers are similar [but not identical] for TDES. See the
Encryption Facility for z/OS Performance and Sizing paper from
WSC at (watch for the wrap):
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/5cb5ed706d254a8186256c71006d2e0a/12bac1d600d52b85862570dc0073b002/$FILE/EF%20Sizing_V2.pdf
6. I would rather see eligible data encrypted on the mainframe,
instead of just at the tape I/O level. If sensitive data is only
encrypted on tape, then that means sensitive data is NOT encrypted
on the mainframe and is vulnerable to exposure. If the data is always
encrypted on the mainframe, then archiving to tape is a simple copy
job and it is less vulnerable to exposure.
True. But there are certain overheads, and you need to have the
data in the clear to process it.
7. An upside to external encryption is that it minimizes impact to
legacy applications. A CPU-based encryption solution requires some
kind of change to an application I/O to perform the ciphering. This
can be a direct change to the application or maybe through a front-end
of OPEN SVC and the GET/PUT/READ/WRITE routines. Changing a perfectly
good application is a serious matter to many shops. So, a behind-the-scenes
solution is preferable. However, sometimes external forces, like Sarbanes-
Oxley, may require shops to change their applications anyway to include
auditing and logging required by regulations or other policy decisions.
That is a good time to also add compression/encryption.
The Encryption Facility requires only JCL changes to add a
post-processing encryption step, not application code changes. I
think this is also true of at least some (perhaps even all) the
other vendors' competitive products.
<snip>
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
