[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TO COMPRESS OR NOT TO CMPRS (please reply)
I'm against coupling compression with IPSEC. I don't believe that this is
the correct place to put it and I am not convinced that putting it there
will actually improve overall performance. The burden of proof should be
on those proposing this to show that there is a reasonable degree of
certainty that this makes good engineering sense. I am not yet convinced.
A few thoughts on the issues...
Compression must be negotiated or else it cannot be deployed. This leads
to want to do it as a TCP option or as an ISAKMP attribute.
Doing it in IPSEC before ESP does not help with the fragmentation issue.
The fragmentation issue is solved by having IPSEC manage the routing layer
when it creates an association. We have implemented this in our Windows 95
IPSEC stack for both Tunnel and Transport modes of AH and ESP and it seems
to work.
You want to compress before TCP has fragmented the packet, not after it.
>From a performance perspective, you'd much rather deal with less packets
than with smaller ones. That's true both for encryption (as Dan Harkins
pointed out) and TCP in general (as Bill Sommerfield observed). This is
very important and implies pushing compression up into TCP.
It is not clear that compressing protocols other than TCP will be a win.
And with TCP, it is certain that there is a fair amount of traffic that
will not benefit from compression either because it's relatively small
(single-character TELNET) or because it has already been compressed at the
application (graphics/video/audio). Doing compression on these packets is
a waste of time.
A compression algorithm might be able to tell that it's losing, but it's
already wasted the cycles at that point. Whether or not compression will
help is an attribute of the data that only the sending application really
has a chance to assert a priori.
Compression is useful indepedent of IPSEC, though in the absense of IPSEC,
it's probably better handled by underlying hardware.
This is leading me to believe that if we are to add this, this should be
added as a negotiated TCP option along with a strong suggestion to stack
vendors to implement a per-socket option to allow applications to enable or
disable compression on the fly.
However, I remain unconvinced that simply adding compression will be the
big win some folks seem to think it will be. Just because encryption makes
in infeasible to do compression afterward doesn't necessarily mean that you
want to do compression beforhand.
Derrell
Follow-Ups: