Re: TO COMPRESS OR NOT TO CMPRS (please reply)

["Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" <[e-mail]>]

Perry wrote:
> I see you haven't heard of SSL, eh?
>
> Security is very big on the web. People -- and I mean ordinary
> consumers -- want to conduct transactions over it. With a reasonable
> IPSec in place, SSL wouldn't have been necessary. SSL is used every
> day by millions of people to keep their credit card data away from
> prying eyes.
>

Perry is right here, it is our intention to move toward full encryption
on all sessions across public networks first and later toward the same
on internal communications.

Bob wrote:
> The issue for doing the work is less a burden for the client than it is for
> the server. I completely agree that at the client end, the overhead is
> unnoticeable. However, at the server/aggregation points for all these
> clients, the workload would be substantial, if not overwhelming (i.e.,
> without hardware assist). This is true in the case for compression today.
> In some routers that support PPP compression today, if the load on the
> router becomes too great so that the network pipe can't be kept saturated,
> the compression is turned off.
>

Bob is right on this point.  We are expecting to see lots of encryption
engine products turn up allow support of encryption at the servers.
Maxing a server with a single 20 megabit DES stream won't cut it if we
intend to do much deployment of IPSEC.  We also expect to be looking at
light-weight encryption solutions for non-critical sessions.  Encrypting
only critical sessions is just asking for attention you don't want.
From this point, it is conceivable that some of these light-weight solutions
could be not much more than compressed sessions with light topping of
of hash or cypher.

The solution seems to be which of these combinations has the smallest cost
in cycles for the users particular session:

    A)  Total overhead cycles = "encryption only"
    B)  Total overhead cycles = "compression and then encryption"  

If I'm sending CAD, GIFs, or other barely compressable objects, it would
seem likely A is the answer.  On the other hand, if it is email or a
few thousand pages of maintenance manual, B is probably the cheapest.
(Assuming of coarse equal heavy weight encryptions for both cases)

From this perspective, being able to negotiate both the encryption and
compression seem to give the end user the best ability to secure their
session and manage the cost of their security.

Answer in our case seems to be "optional compression".

Just as another thought, someone (forgot who) in the bulk of mail on this
subject, stated or implied that saving "network bandwidth" was the most
important goal.  I suspect that savings "server CPU cycles" will far
outweight "network bandwidth" concerns in at least our case.

Take care

   | Terry L. Davis, P.E. | Boeing Information & Support Services |
   | Phone: [phone]  |       Bellevue, Washington, USA       |
   | Email: [e-mail].                             |
   --------------- Wednesday February 19,1997 12:32 PM PST ------------- 

PS: Can we manage that much flexibility on day one; probably not.  But
    on the other hand a CAD server has a certain basic profile and a
    manual server has another so perhaps we may do better than one
    would expect at first glance.