RE: TO COMPRESS OR NOT TO CMPRS (please reply)
Bob Monsour <rmonsour@earthlink.net> Wed, 19 February 1997 06:36 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA20510 for ipsec-outgoing; Wed, 19 Feb 1997 01:36:57 -0500 (EST)
Message-Id: <3.0.32.19970218224038.00952df0@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Feb 1997 22:40:41 -0800
To: adams@cisco.com
From: Bob Monsour <rmonsour@earthlink.net>
Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com, rmonsour@earthlink.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 03:39 PM 2/18/97 -0800, Rob Adams wrote: >I would much rather see compression negotiated as part of the ISAKMP exchange >and used for all traffic associated with an SA. I don't think adding any bits is necessary. >As Naganand said, we already have enough bits and options. Rob, Compression would indeed be negotiated as partof the ISAKMP exchange. Allowing selective compression on a packet by packet basis provides implementation flexibility. For example, you may want to avoid compressing packets less than 100 bytes; or want to send uncompressed data because the data expanded (was precompressed or pre-encrypted at the application layer). You could easily do this using the compressed/not-compressed bit as proposed. To avoid using the bit, you would have to have two SA's for each direction of the connection: one to use for compressed data and one to use for uncompressed data. Are system resources (SA's) that free that a potential doubling of their use is acceptable? I would argue that use of a single bit per packet (an existing bit, not an additional one) is preferable to managing two SA's per direction on each connection. Seems like comparable complexity at best. ...snip... >I prefer ISAKMP negotiation because it will allow me to implement it up higher in my stack >than the IP layer. I think that compressing at the IP layer isn't going to buy you a whole >lot in speed since you're going to be sending out the same number of packets. >If I have a confirmed negotiated compression algorithm/state, my implementation >can do compression in the appropriate place, above the fragmentation done by >TCP. Firewalls can do compression before they encrypt or whatever, but then >I'll just get a lot of small encrypted packets from a firewall. A firewall will get >fully packed, compressed and encrypted packets from me. That's better than nothing. > >The choice of what layer to process compression at should be an implementation detail >as long as it is done before encryption and decompressed after decryption. In this way, >compression may be useful to things other than IPsec and ESP in particular. Lumping >compression on ESP doesn't allow us a general compression solution. The problem, as I've stated in other responses, is that there is not a universal "higher layer" in which to do compression. It is more than an implementation detail. All parties wanting to compress would have to support it at this "higher layer" which may or may not be present. IP is the common denominator and the need for compression at the IP layer is partly because of the encryption. In the absence of encryption, for systems using PPP, the PPP compression will be effective. ...snip... >I'd like to see more investigation of how useful compression is before we commit to anything though. >I have a lot of questions about how much we'll gain for what kinds of traffic and over links that do >hardware compression like some modems and routers. Am I the only one that feels like we're rushing >this without enough information? In a response to another message in this thread, I provided a table of compression ratios for text data, analyzed on the basis of packet size. I will work on providing similar results on other types of data, but this is publically available data used for comparing compression ratios for different compression algorithms (see draft-sabin-lzs-payload-00.txt). For links that do hardware compression (modems & routers), once you encrypt at a the IP layer, those compressors are no longer effective (encrypted data doesn't/shouldn't compress). Your questions are useful in the debate and are appreciated. -Bob
- TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Matt Thomas
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Derek Palma
- RE: TO COMPRESS OR NOT TO CMPRS (please reply) Roy Pereira
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- RE: TO COMPRESS OR NOT TO CMPRS (please reply) Rob Adams
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Derrell Piper
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Terry L. Davis, Boeing Information & Support Services, Bellevue, WA
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Dennis Glatting
- RE: TO COMPRESS OR NOT TO CMPRS (please reply) Rob Adams
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Michael Richardson
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Kent Fitch
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Daniel Harkins
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Germano Caronni
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Marcel Waldvogel
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Rodney Thayer
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Derek Palma
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) carrel
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Matt Thomas
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Daniel Harkins
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Karl Fox
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Naganand Doraswamy
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) C. Harald Koch
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) C. Harald Koch
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Steven Bellovin
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Karl Fox
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Karl Fox
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Angelos D. Keromytis
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Scott Marcus
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Matt Thomas
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Angelos D. Keromytis
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Dennis Glatting
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Stephen Kent
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- RE: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Jim Thompson
- RE: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Perry E. Metzger
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) C. Harald Koch
- RE: TO COMPRESS OR NOT TO CMPRS (please reply) Roy Pereira
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Perry E. Metzger
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) EKR
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) John W. Richardson
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bill Sommerfeld
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bill Sommerfeld
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) C. Harald Koch
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bill Sommerfeld
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- RE: TO COMPRESS OR NOT TO CMPRS (please reply) Rob Adams
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Angelos D. Keromytis
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Dennis Glatting
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) EKR
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Rodney Thayer
- RE: TO COMPRESS OR NOT TO CMPRS (please reply) Stephen Kent
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Stephen Kent
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Stephen Kent
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Dennis Glatting
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Phil Karn
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Phil Karn
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Phil Karn
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Phil Karn
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Bob Monsour
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Marcel Waldvogel
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Stephen Kent
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Perry E. Metzger
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Perry E. Metzger
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) Phil Karn
- Re: TO COMPRESS OR NOT TO CMPRS (please reply) James Hughes