RE: IPCOMP and IPSEC
Avram Shacham <shacham@cisco.com> Fri, 29 May 1998 17:27 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04036 for ipsec-outgoing; Fri, 29 May 1998 13:27:55 -0400 (EDT)
Message-Id: <3.0.2.32.19980529103610.006b4914@airedale.cisco.com>
X-Sender: shacham@airedale.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Fri, 29 May 1998 10:36:10 -0700
To: Stephen Waters <Stephen.Waters@digital.com>
From: Avram Shacham <shacham@cisco.com>
Subject: RE: IPCOMP and IPSEC
Cc: ipsec@tis.com, ippcp@external.cisco.com
In-Reply-To: <250F9C8DEB9ED011A14D08002BE4F64C01A23E44@wade.reo.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve, At 11:56 AM 5/29/98 +0100, Stephen Waters wrote: >The IP-layer compression (IPPCP) calls >for zero-history compression - for which the performance can be bad. Tests show different results. Sure, an IP datagram with payload that has been previously compressed tends not to compress any further, regardless of the protocol-layer the compression is applied in. In other words, compressed data will not compress further in V42.bis, PPP, or IPComp. Therefore the IPComp protocol recommends implementation of an adaptive algorithm to avoid the performance hit. Using the Calgary files benchmark with LZS algorithm, the compression ratio of IP datagrams with MTU of 1500 octets was 1.82:1, not that far from the max the algorithm can offer 2.2:1. Stateless compression is a must in IP, so the overall performance gain is pretty significant. And, stateless compression has its implementation advantages. >When we did LZS zero-history support for X.25 links, we used a minimum >packet size of 500bytes, i.e. we would not even try to compress the >packet if it was smaller than that. My measurements of LZS with MTU of 576 show a compression ratio of 1.5:1. MTU of 256 gave a similar ratio, but 41% of the packets failed to compress, so overall performance got a hit. The IPComp protocol does recognize that small datagrams are likely to expand as a result of compression. Therefore, the protocol suggests that a numeric threshold should be applied before compression, where IP datagrams of size smaller than the threshold are sent in the original form without attempting compression. The numeric threshold is implementation dependent. The algorithms drafts (DELATE, LZS) suggest using a threshold of ~90 bytes. My implementation uses the value of 256. >On my office link (ISDN/PPP/LZS with history), I average 2:1 >compression. I suspect this would reduce noticeably for zero-history. You may be surprised, and - again - for the better. On my home-office link (IPComp/ISDN) I got 1.82:1 compression ratio - with or without ESP encryption. Regards, avram
- IPCOMP and IPSEC Stephen Waters
- Re: IPCOMP and IPSEC Daniel Harkins
- Re: IPCOMP and IPSEC Vach Kompella
- Re: IPCOMP and IPSEC Naganand Doraswamy
- RE: IPCOMP and IPSEC Roy Pereira
- Re: IPCOMP and IPSEC Daniel Harkins
- FW: IPCOMP and IPSEC Stephen Waters
- RE: IPCOMP and IPSEC Roy Pereira
- Re: IPCOMP and IPSEC Daniel Harkins
- RE: IPCOMP and IPSEC Roy Pereira
- Re: IPCOMP and IPSEC Marc Hasson
- Re: IPCOMP and IPSEC Daniel Harkins
- Re: IPCOMP and IPSEC Marc Hasson
- Re: IPCOMP and IPSEC Saroop Mathur
- RE: IPCOMP and IPSEC Stephen Waters
- Re: IPCOMP and IPSEC Eric Dean
- RE: IPCOMP and IPSEC Avram Shacham
- RE: IPCOMP and IPSEC Avram Shacham
- RE: IPCOMP and IPSEC Eric Dean
- RE: IPCOMP and IPSEC Stephen Waters
- RE: IPCOMP and IPSEC Eric Dean
- RE: IPCOMP and IPSEC Eric Dean
- Re: IPCOMP and IPSEC Stephen Kent
- RE: IPCOMP and IPSEC Robert Moskowitz
- RE: IPCOMP and IPSEC Avram Shacham
- RE: IPCOMP and IPSEC Paul Koning